Repository navigation
perf(index): run supervised index workers at below-normal CPU priority - #2838
halindrome wants to merge 1 commit into
Conversation
A full index saturates every core in the parallel extraction pass, and interactive CLI/MCP queries (CPU-bound at start-up) were measured taking twice their wall time behind it with flat CPU time: pure run-queue contention. The index-worker role now lowers its own priority once, before any indexing thread is created: nice 10 on POSIX, BELOW_NORMAL_PRIORITY_CLASS on Windows. It never raises priority: a process already nicer than 10 (or in the IDLE / BELOW_NORMAL class) is left alone. Plain nice only, not macOS background QoS, which would pin indexing to efficiency cores and throttle its I/O. Failure is logged and ignored. The test runs the helper in a forked child and checks both legs: a normal-priority child ends at nice >= 10, and a child started nicer than that is left where it was. Refs DeusData#2834 Signed-off-by: Shane McCarron <shane.mccarron@corvexconnect.com>
QA Round 1Contract: #2834 + PR acceptance criteria (CPU-priority half only; the per-call executable hash is out of scope) Contract Verification
Finding 1 — Windows path can raise an IDLE-class worker to BELOW_NORMAL
The POSIX branch checks the current nice value before changing it. The Windows branch calls Expected: return early when the current class is already Finding 2 — No test covers the worker-role wiring
The new test exercises the helper on its own. Removing the 6-line block in Expected: some test fails if the index-worker role stops lowering its priority. Finding 3 — New test passes vacuously under an already-niced runner; the "never raise" branch is never exercised
The test asserts only Expected: record the starting nice and assert a strict change when it starts below 10. Add a leg that starts above 10 and asserts the value is unchanged. Summary
Panel: contract-security, regression-edges, test-quality. All 3 lenses landed on ObservationsNone. SAST review not applicableTarget QA performed by Claude Code (claude-opus-5-5), manager + 3-lens panel Dispositions (orchestrator, Step 3B)
Verification
QA-Fix-Commit: 704a208 Posted by the developer account (QA-agent token unavailable). Review by Claude Opus 5.5 (Anthropic) in Claude Code via qa-panel. |
QA Round 2Scope: PR #4 ( Contract VerificationContract: upstream issue #2834 + PR acceptance criteria.
Finding 1 — [claude] No test pins the index-worker wiring: removing or moving the main.c call fails nothing
Finding 2 — [claude] Helper test passes vacuously when the test runner is already at nice >= 10
Summary
No blocking findings. Both minors are test-coverage gaps. Neither is on code that round 1 introduced. ObservationsNone. Fix review: <filled in by main after Step 3B> SAST review not applicableTarget QA performed by Claude Code (claude-opus-5-5), manager + 3-lens panel Dispositions (orchestrator, Step 3B)No code changed this round. Both minors were declined as known test limits:
Cycle outcome: clean of critical and major findings after round 2, and every contract criterion passes. Not approved: no QA-agent token is available, and approval is the human reviewer's call. Posted by the developer account (QA-agent token unavailable). Review by Claude Opus 5.5 (Anthropic) in Claude Code via qa-panel. |
|
Thanks for opening this — it has been seen, and it is queued. This note is automated, but it is not a brush-off: it exists so you know where your PR stands instead of having to guess from silence. Current review status: working through a backlog. What that means for this PR, concretely:
Things that will genuinely speed it up whenever review does happen:
If this fixes a bug, a reproduction we can run is worth more than a description of the symptom. Thanks for contributing, and sorry in advance for the wait. |
Summary
Run supervised index workers (
cli --index-worker) at below-normal CPU priority so a long full index can't starve interactive CLI/MCP queries.Closes #2834
During a full index the parallel extraction pass saturates every core. One-shot
codebase-memory-mcp cli <tool>queries are CPU-bound at start-up, and measurement showed their wall time doubling during an index while their CPU time stayed flat — run-queue contention, not a lock (same-project and other-project queries behaved identically). Nothing insrc/lowered worker priority before this change.Change
cbm_lower_cpu_priority()(src/foundation/platform.c/.h): POSIXsetpriority(PRIO_PROCESS, 0, 10); WindowsBELOW_NORMAL_PRIORITY_CLASS. It never raises priority: an already-nicer process, or one in the IDLE / BELOW_NORMAL class, is left alone. Plain nice only — not macOS background QoS, which would pin indexing to efficiency cores and throttle its I/O.run_cli(src/main.c) calls it once in the index-worker role, before any indexing thread exists, so every pipeline thread inherits it. Failure is logged at info and ignored.Acceptance criteria
Testing
platform_lower_cpu_priority_nices_the_process(tests/test_platform.c): forks a child, calls the helper, and reportsgetprioritythrough a pipe. It checks two things:scripts/test.sh --suites platform,index_supervisor,index_resilience,worker_pool,cli: 442 passed, 1 pre-existing skip, 0 failed.🤖 Generated with Claude Code
https://claude.ai/code/session_01CDDUoWEZMNZ9fLvzp2pPGT