Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

[Perf] Linux: Grok sessions walk /proc every 25 ms on the server event loop, although the cgroup lease already handles teardown

Open Beginner friendly
  • Is something wrong?
#23,393 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
78/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
linux, typescript
Domain
backend, performance

Research direction

Start in packages/provider-acp/src/server/AcpSessionRuntime.ts at the cgroup lease setup and continuous ownership observer. Check the teardown branches to confirm the ownership ledger is only used without a lease, then add or update the counting-controller test described in the issue. Done means the observer captures the root once under a lease, idle polling stops, and closing the session empties the lease.

Written by the indexing model from the issue text.

Description

The problem

On Linux, when a Grok session has a cgroup v2 lease (t3-acp-*, the normal case under systemd),
AcpSessionRuntime still runs observePosixOwnershipLedgerContinuously for the whole life of the
session. Every 25 ms it walks the agent's process tree in /proc on the server's main thread. Its
result (the ownership ledger) is read only by terminatePosixProcessTree, which runs only when
there is no lease. Under a lease, teardown is cgroup.kill plus the root identity captured
once at spawn. The walk is unused work on the event loop.

Claude and Codex sessions have no equivalent. They are spawned detached and torn down with one
kill(-pgid) (ClaudeAdapterV2.ts:320, provider-core/src/server/processGroup.ts). Of the
providers in this repo, only provider-grok sets ownDescendantProcessGroups.

Measured impact (T3 v0.1.1, fe27e8e3, headless t3 serve, Ubuntu 26.04, cgroup v2)

Controlled test on one server process. Each Grok session was a task whose only action was
sleep 300. Per session: grok agent --always-approve stdio (46 threads) and
t3 acp-mcp-bridge (11 threads) in their own lease. Main thread measured with
/proc/<pid>/task/<pid>/stat and bpftrace raw_syscalls filtered to the main thread.

Grok sessions main thread CPU main-thread /proc opens/s getdents64/s kernel time in these calls
0 (Claude and Codex sessions live) 6.8% of a core 0 0 —
1, idle 15.6% 2,415 284 5.6% of a core
3, idle 24.6% 6,390 759 12.9% of a core
3, turns finished, sessions still open 21.0% 5,858 395 11.6% of a core
0, after the 30 min idle release 10.2% 0 0 0.03% of a core
  • An idle session runs the walk at the full rate: about 40 passes/s × (one task/<tid>/children
    read per agent thread + stat and readlink exe per process). The cost scales with sessions and
    with the agent's thread count.
  • It lasts beyond the turn. Idle provider sessions are released after DEFAULT_IDLE_TIMEOUT_MS
    (30 min, up to 4 h when pinned; ProviderSessionManager.ts:56-57). The test sessions were
    released 30 min after their last activity, and the /proc traffic stopped with them.
  • Under load the walk runs slower (we saw about 5 passes/s on a busy server), because it shares
    the main thread. Then it shows up as event-loop delay instead of CPU.

This is the measurement requested when #19255 was closed.

Root cause

packages/provider-acp/src/server/AcpSessionRuntime.ts @ fe27e8e3:

  1. Grok enables descendant ownership on Linux:
    provider-grok/src/server/acpSupport.ts#L90-L101.
  2. That creates a cgroup v2 lease and joins the agent to it before exec:
    L1402-L1421.
  3. Without checking for the lease, it then forks the continuous observer for the session's
    lifetime:
    L1493-L1534,
    loop at
    L739-L758
    (25 ms target, inside Effect.sync, so each pass blocks the event loop).
  4. With a lease, graceful teardown
    (L1596-L1609)
    and forced teardown
    (L1624-L1641)
    use only the root identity from the initial capture and terminateLinuxCgroupLease. The ledger
    is consumed only by terminatePosixProcessTree, reached when linuxCgroupLease === undefined.

Proposed fix

Start the continuous observer only when there is no lease. The initial root capture stays, so
signalLinuxCgroupRootTerm still targets the right pid:starttime. Sessions without a lease
(cgroup v1, no delegated cgroup) behave exactly as today.

-    yield* observePosixOwnershipLedgerContinuously({
-      childQueues: posixOwnershipChildQueues,
-      controller: posixController,
-      frontier: posixOwnershipFrontier,
-      ledger: posixOwnershipLedger,
-      root: posixOwnershipRoot,
-      rootPid: Number(child.pid),
-    }).pipe(Effect.forkIn(runtimeScope));
+    // Under a cgroup lease, teardown is cgroup.kill and reads only the root captured above.
+    if (linuxCgroupLease === undefined) {
+      yield* observePosixOwnershipLedgerContinuously({
+        childQueues: posixOwnershipChildQueues,
+        controller: posixController,
+        frontier: posixOwnershipFrontier,
+        ledger: posixOwnershipLedger,
+        root: posixOwnershipRoot,
+        rootPid: Number(child.pid),
+      }).pipe(Effect.forkIn(runtimeScope));
+    }

Test: with a counting fake posixProcessTreeController and a temp-directory lease, assert that
childPidsOf runs once (the initial capture) over an idle window of 10+ intervals, and that closing
the session still empties the lease. #19255 had this test (8 reads instead of 1 on main).

Expected result

Under a lease: 0 /proc opens from idle Grok sessions, the same as Claude and Codex, and about
5–9% of a core of main-thread time back per open Grok session.

Dominant language
TypeScript
Stars
24.8k
Forks
6.4k
Avg merge
1h 22m
Merged PRs (30d)
18

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from pingdotgg/t3code

All issues in pingdotgg/t3code

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.