Perf: explain and bound RSS after cancelling a 32-worker storm

[Hmbown]

Problem

The new 32-worker PTY benchmark proves that high fan-out is responsive enough to operate, but its one-shot RSS sample increased again after cancellation instead of settling. We should distinguish allocator high-water retention from a real worker/runtime leak and bound the post-cancel state.

Evidence

Live macOS run on 2026-07-09 from the #4316 release-runtime QA lane:

• 32 workers live: 1.36s
• sidebar visible: 1.98s
• typing echo samples: 137–925ms
• Esc cancellation: 0.80s
• RSS: about 62MB idle → 178MB during storm → 328MB immediately after cancellation

The interaction acceptance passed; the 328MB post-cancel sample is the residual signal. The benchmark is loopback-only and makes no paid provider calls.

Reproduction:

cargo test -p codewhale-tui --test release_runtime_qa --locked -- \
  --ignored bench_thirty_two --nocapture --test-threads=1

Expected behavior

Cancellation should terminate all 32 child tasks promptly and memory should reach a stable, explainable plateau. If mimalloc intentionally retains pages, the benchmark/report should separate allocator retention from reachable worker/session state rather than treating raw RSS as a leak by default.

Likely inspection points

• crates/tui/tests/release_runtime_qa.rs (release_bench_thirty_two_worker_fanout_stays_live)
• sub-agent task/record teardown in crates/tui/src/tools/subagent/
• runtime thread and completion-channel ownership
• transcript/activity caches that retain child output after cancellation
• mimalloc purge/high-water behavior on macOS

Acceptance criteria

• Sample RSS at idle, storm, cancel, +5s, +15s, and +30s across at least three runs.
• Prove all child tasks/processes/channels are terminal after cancel.
• Identify retained reachable state versus allocator-reserved pages.
• If reachable state leaks, fix it and add a regression assertion.
• If allocator retention is expected, document it and add a stable plateau bound that does not create flaky CI.
• Keep 32-worker spawn, typing echo, and cancellation latency within the v0.8.68 Performance: TUI lag and memory pressure from high agent fan-out sessions #4014 thresholds.

Related

• v0.8.68 Performance: TUI lag and memory pressure from high agent fan-out sessions #4014 — v0.8.68 high-fanout responsiveness
• test: isolate hotbar skill cache and automate live TUI QA targets #4316 — automated PTY QA and 32-worker benchmark fixture
• fix(subagents): age-evict terminal worker_records (#4217) #4296 — bounded terminal worker-record retention
• perf(tui): rebased hotpaths from #3902 (#3896/#3898/#3900) #4304 — landed render/input hot-path improvements

[cyq1017]

I reproduced the loopback benchmark locally. After Esc, the TUI process still held 32 established provider connections; the direct child agents are launched through background_runtime(), so the parent turn token does not cancel them. That matches the existing #3216 background-worker contract, while #4326 expects cancellation to terminate all 32 children.\n\nCould you clarify the intended scope for Esc here: should it cancel only agents created by the active turn (which would need turn ownership on root workers), or should detached agents keep the current behavior and the benchmark explicitly cancel its children? I can prepare the narrow regression/fix once that contract is chosen.