Cpu sample rate #68

Merged
mi merged 2 commits from cpu-sample-rate into main 2026-09-15 13:29:58 +02:00
Owner
No description provided.
mi added 2 commits 2026-09-15 13:29:30 +02:00
Once a second loses everything the tree burns after the last reading,
and the tree is gone before anyone can ask again. For a build of minutes
that is a rounding error; for a build of a second or two it is most of
the figure. PR#67's own test found it on the first CI run: a three-second
burn recorded as less than one.

The reading costs about a millisecond, so five a second is half a percent
of one core and the worst-case loss is a fifth of a second. The test now
asserts milliseconds, which is what the figure is, and the queue test from
PR#66 gets the thirty-second window the rest of that spec uses.

Also corrects a claim in the fallback path: without CONFIG_PROC_CHILDREN
a build records only the root and what it has reaped, which is little,
not "most of it". The host's kernel lists children; verified directly.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The test submitted the deployment and the second build one after the
other and expected them to reach the single slot in that order. They run
in worker threads of their own, so whichever gets there first takes it:
with the order reversed the second build finished before the deployment
started, and the scenario's premise never held. The failure on the host
said exactly that -- main@deploy PENDING because the other build had the
slot. Raising the timeout would only have made it rarer.

The second build is now enqueued once the deployment is running.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
mi merged commit 762afb589a into main 2026-09-15 13:29:58 +02:00
mi deleted branch cpu-sample-rate 2026-09-15 13:29:58 +02:00
Sign in to join this conversation.
No Reviewers
No labels
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mi/werkator#68