jcp-energy: the RAPL probe tests advance their fake zones on the probe's own tick #272
Loading…
Reference in a new issue
No description provided.
Delete branch "fix/rapl-probe-test-starvation"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
What was wrong
Two jcp-energy tests check the RAPL liveness probe on fake powercap trees:
the_rapl_probe_on_fake_powercap_treesrapl_sums_and_probes_the_package_zones_onlyIn both, a second thread advanced the fake zones on a 2 ms timer while the probe's tick burned CPU on the calling thread. On a loaded CI host that thread was starved, the sampling intervals went flat, and two live packages read Frozen.
It failed #270's jcp-rs leg (job 29211: "both packages advancing, psys and dram holding, was not live"), although #270 does not touch jcp.
The fix
rapl_status_tickingruns RAPL's probe with its real opener, sampler, CPU-burning tick, clock and budget. After each tick it adds the fake hardware's rise, on the probe's own thread. Every interval then sees exactly the rise the test means, so the verdict comes from the probe's rule rather than from the scheduler.rapl_status_on, the real composition, is still exercised by the same tests' Frozen and Unavailable cases.Checked
On the build host:
cargo test -p jcp-energy --features nvmlpasses.🤖 Generated with Claude Code