jcp-energy: the RAPL probe tests advance their fake zones on the probe's own tick #272

Merged
dcharlot merged 1 commit from fix/rapl-probe-test-starvation into main 2026-10-16 04:39:57 -04:00
Owner

What was wrong

Two jcp-energy tests check the RAPL liveness probe on fake powercap trees:

  • the_rapl_probe_on_fake_powercap_trees
  • rapl_sums_and_probes_the_package_zones_only

In 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_ticking runs 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:

  • The two tests passed in 10 of 10 runs: Live after ~311 ms while both packages rise, and Frozen at the 1 s budget while one holds.
  • cargo test -p jcp-energy --features nvml passes.
  • Clippy is clean.

🤖 Generated with Claude Code

## What was wrong Two jcp-energy tests check the RAPL liveness probe on fake powercap trees: - `the_rapl_probe_on_fake_powercap_trees` - `rapl_sums_and_probes_the_package_zones_only` In 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_ticking` runs 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: - The two tests passed in 10 of 10 runs: Live after ~311 ms while both packages rise, and Frozen at the 1 s budget while one holds. - `cargo test -p jcp-energy --features nvml` passes. - Clippy is clean. 🤖 Generated with [Claude Code](https://claude.com/claude-code)
jcp-energy: the RAPL probe tests advance their fake zones on the probe's own tick
All checks were successful
energy meters on real hardware / RAPL and NVML on jetson-hub (pull_request) Successful in 55s
standards workspaces build + test / which workspaces this change touches (pull_request) Successful in 6s
repository checks / lockfiles, tests in CI, workflow hygiene, spec and section references, public text (pull_request) Successful in 1m0s
standards workspaces build + test / mesh-rs (mesh/mesh-rs, -p mesh-engine-gguf -p mesh-openai --features mesh-engine-gguf/gguf,mesh-openai/server, mesh-rs, linux-arm64) (pull_request) Successful in 1m25s
standards workspaces build + test / joule-code-rs (joule-code/joule-code-rs, joule-code-rs, linux-arm64, true) (pull_request) Successful in 2m28s
standards workspaces build + test / jouleclaw-rs (-nodebug, jouleclaw/jouleclaw-rs, -p jouleclaw-energy --features rapl,nvml, jouleclaw-rs, linux-arm64, -C target-feature=+fp16) (pull_request) Successful in 4m25s
standards workspaces build + test / macOS energy backends (pull_request) Successful in 7m49s
standards workspaces build + test / jouledesk-rs (jouledesk/jouledesk-rs, jouledesk-rs, macos) (pull_request) Successful in 1m26s
standards workspaces build + test / jcp-rs (jcp-conformance, jcp/jcp-rs, -p jcp-energy --features nvml, jcp-rs, linux) (pull_request) Successful in 1m45s
standards workspaces build + test / joule-ui-rs (joule-ui/joule-ui-rs, joule-ui-rs, linux) (pull_request) Successful in 1m13s
standards workspaces build + test / joulehook-rs (joulehook/joulehook-rs, joulehook-rs, linux) (pull_request) Successful in 1m14s
standards workspaces build + test / sandbox-rs (sandbox-conformance, sandbox/sandbox-rs, sandbox-rs, linux) (pull_request) Successful in 2m30s
8e41b48e36
Two tests checked the RAPL liveness probe on fake powercap trees:
`the_rapl_probe_on_fake_powercap_trees` and
`rapl_sums_and_probes_the_package_zones_only`. 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 intervals
went flat, and two live packages read Frozen. It failed PR #270's jcp-rs
leg (job 29211: "both packages advancing, psys and dram holding, was not
live"), and that PR does not touch jcp.

`rapl_status_ticking` runs RAPL's probe with its real opener, sampler,
CPU-burning tick, clock and budget, and adds the fake hardware's rise after
each tick, on the probe's own thread. Every interval sees exactly the rise
the test means, so the verdict comes from the probe's rule and not from the
scheduler. `rapl_status_on`, the real composition, is still exercised by
the same tests' Frozen and Unavailable cases.

On the build host the two tests passed in 10 of 10 runs (Live in ~311 ms,
Frozen at the 1 s budget). The full suite passes with `--features nvml`.

Co-Authored-By: Claude Opus 5.5 <[email protected]>
Sign in to join this conversation.
No reviewers
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
Transaction-Science/open-standards!272
No description provided.