The macOS energy job's process_gpu test gave up when a GPU client vanished in six spans in a
row: its checks needed a span in which no client of the shared host vanished, and on a host
whose other sessions open and close GPU clients every second there may be none. Reproduced on
the build host beside a churner of short-lived GPU clients of our own: at one every 0.75 s, 4 of
4 runs gave up; at one every 1.5 s each run took 2-4 tries. Two other failures had the same
root: the oracle's sum over every client gave up when one went back inside its window (job
27254, the `.expect` on `oracle_times`), and fell below the counter's when a client came and went
inside the span (job 48857, the every-client assertion).
No span now needs to be free of churn. Each span of the counter's or the span meter's is
bracketed by `ioreg` listings of the registry, read independently of the counter: before it,
around its work and after it. `classify` sorts every client against them. A registry entry once
destroyed never comes back and its ID is not reused, so:
- a client two reads list is in every read between them, under one pid; anything else is a
contradiction and fails the test: a client the end snapshot lacks while `ioreg` lists it after
(step 5's own check, now on every span), one the start lacks while `ioreg` listed it before and
after, one both snapshots hold that `ioreg` did not list around the work, one gone inside the
work and back in the end snapshot;
- a client's time goes down only where a queue of it closed, which the listings show as a fall,
so each counter reading lies between the listings either side of it, or on one side of a fall
across it; a reading the registry does not explain voids the span;
- a client the counter saw vanish is corroborated if `ioreg` listed it under the same pid (gone)
or showed its fall inside the span (gone back); one `ioreg` never listed voids the span;
- a client only `ioreg` listed inside the span, or a fall it showed where the counter saw an
advance, is GPU time the counter's snapshots cannot hold, counted as hidden, a lower bound;
- this process's own clients must be clean, or the span is void.
A void span is taken again after 0.5, 1, 2, 4, 8, 8 ... s, and none the registry vouches for in
90 s fails as `process-gpu INCONCLUSIVE`, with each reason's count: not a verdict, and not a
pass. A refusal must be the registry's: a corroborated vanished client refuses the span, naming
the client the meter's rule picks (`expected_refusal`, factored out of step 5), and with none the
span is not refused. The checks then run on the view, the snapshots with the vanished clients
taken out of both, which can only raise this process's share.
`agrees_with_oracle` checks client by client. This process's GPU time equals `ioreg`'s exactly,
as before. The clients whose time went down nowhere advanced at most the oracle's advance plus
what the gap can hold (their lower bound is now the sorting's, per client). The meter's
every-client time is the sum over the view's clients. The rail is checked against the test's own
IOReport read on every span whose snapshots both read it current, shared ones included (it had
been on sole-user spans only), and a figure's rail is the snapshots' own advance. A figure must
be a sole user's share of the time the counter saw plus the time hidden from it. `oracle_times`
and its give-up are gone.
Steps 4c and 6 take the span meter's span through `finish_showing_gpu` (the previous commit) and
check that it is the GPU counter's figure, or the CPU alone with the counter's reason, over the
meter's own snapshots, where the test had picked a span out of six by the text of its reason. A
corroborated refusal is accepted there as the CPU alone, `HwShunt`, `Partial`, with CPU energy.
Step 5's span-meter span gives the counter's reason over its own snapshots. The idle spans of
steps 3 and 4a, and 4c's CPU-only span, also assert that `ioreg` saw no GPU time of this
process's inside them. After the liveness askers, the test waits, at most 3 s and never failing,
for this process's own clients to settle.
the_span_classifier_sorts_every_client drives `classify` over six built reads: clean; gone and
gone back, with the registry vouching and without; made and destroyed inside the span (48857's
shape); a fall inside the work that the counter saw as an advance (27254's); falls across each
snapshot inside the span and outside it; under- and over-reads; this process's own client not
clean; each contradiction and a pid mismatch; `expected_refusal`'s order; and the 99% gate with
hidden time.
standards-build.yml: the jouleclaw-energy step also greps `process-gpu: oracle-checked:`, which
step 2 prints once its burn was checked against the oracle. MEASURED_ENERGY.md says what the test
checks.
Verified on the build host, at this commit's jouleclaw files: clippy -D warnings on
jouleclaw-energy with `--features ioreport` and without; the macOS energy job's jouleclaw-energy
step as standards-build.yml runs it (under `bash -eo pipefail`, both greps), 5 of 5, three of
them beside a churner of short-lived GPU clients of our own every 0.75 s; and the process_gpu
test 16 of 16, 4 quiet and 4 beside a churner every 3, 1.5 and 0.75 s, with no void span, no
INCONCLUSIVE and no contradiction, every vanished client corroborated on the first attempt. A
read-only walk of the registry the way the counter walks it, every 5 ms for 60 s beside a churner
every 0.2 s (268 clients made and destroyed), found no walk lacking a client the walks either
side of it held and no child iterator invalid at the end of a walk (phantom_walks 0,
invalid_at_end 0, of 7266 walks): a contradiction is a fault in a read, not churn.
Falsified, each failing as named: a start or end walk dropping a client, or giving it another
pid, and a phantom client in both snapshots (contradictions); the counter skipping another
process's vanished client, or giving a figure across a gone one ("the registry vouches for ...
but the counter gave Ok"); refusing a client that did not vanish, or naming another than the
rule's; this process's time and every client's time each 1 ns off; the end snapshot misstating
when it read; the rail under-read by 10%, and a figure's rail not the snapshots' advance; the
sole-user gate at 1%; the span meter's figure, or its reason, not the counter's over its own
snapshots; GPU work in an idle span; the CI grep's line renamed; and the classifier's stretch
rule, fit rule, fall placement, the per-pid oracle, the refusal order and the hidden-time gate,
each broken in turn. Two persistent faults end INCONCLUSIVE, as designed: (c) a 10% under-read of
another process's client in every snapshot, "process-gpu INCONCLUSIVE: 1.5 s burn: no span in 92
s (12 spans) could be checked against the oracle: a counter reading out of the registry's order
×12; ...", and (d) a phantom client in every start snapshot, "... a vanished client the registry
never listed ×12; ...".
Co-Authored-By: Claude Opus 5.5 <[email protected]>
bd46749c27