open-standards/jcp/jcp-rs/crates
Repository files (latest commit first)
Filename Latest commit message Latest commit date
Transaction Science 9333cbd5ee
All checks were successful
standards workspaces build + test / which workspaces this change touches (pull_request) Successful in 6s
standards workspaces build + test / joule-ui-rs (joule-ui/joule-ui-rs, joule-ui-rs, linux) (pull_request) Successful in 30s
standards workspaces build + test / jcp-rs (jcp-conformance, jcp/jcp-rs, -p jcp-energy --features nvml, jcp-rs, linux) (pull_request) Successful in 1m2s
standards workspaces build + test / sandbox-rs (sandbox-conformance, sandbox/sandbox-rs, -p sandbox-tee --features amd-kds,intel-pcs, sandbox-rs, linux) (pull_request) Successful in 1m2s
standards workspaces build + test / joulehook-rs (joulehook/joulehook-rs, joulehook-rs, linux) (pull_request) Successful in 1m30s
repository checks / lockfiles, advisories, tests in CI, workflow hygiene, spec and section references, public text (pull_request) Successful in 1m18s
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 1m8s
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 3m30s
standards workspaces build + test / joule-code-rs (joule-code/joule-code-rs, joule-code-rs, linux-arm64, true) (pull_request) Successful in 6m7s
energy meters on real hardware / sink decode table · per-task energy and the GPU rail on macOS (pull_request) Successful in 2m41s
standards workspaces build + test / jouledesk-rs (jouledesk/jouledesk-rs, jouledesk-rs, macos) (pull_request) Successful in 1m39s
standards workspaces build + test / macOS energy backends (pull_request) Successful in 9m25s
energy meters on real hardware / RAPL and NVML on jetson-hub (pull_request) Successful in 35s
energy meters on real hardware / sink decode table · RAPL on jetson-hub (NVML surveyed) (pull_request) Successful in 2m22s
jcp-energy: RAPL MSR domains are per die on Intel, per package on AMD; die zones are package zones
The MSR fallback grouped CPUs by physical_package_id alone, but Linux scopes
Intel's RAPL counters per die: arch/x86/events/rapl.c gives only AMD and Hygon
a per-package package energy counter, and a multi-die Intel part (Cascade
Lake-AP) has die-scope RAPL MSRs. Reading each package's first CPU there
counts one die, an under-count, the unsafe direction at an energy ceiling.
A counter domain is now, on Intel family 6, the pair (physical_package_id,
die_id), die 0 where the kernel lists no die_id; on AMD and Hygon it stays the
package. Each domain is read on its lowest-numbered CPU and all are summed,
under the same rules: every domain or none, a zero unit is no counter, the
wrap at 2^32 counts, powercap preferred. rapl_access asks the same domains. A
die domain's rail is package-<n>-die-<m> msr where the package has more than
one die, package-<n> msr where it has one.

The powercap side had the matching gap. On such a part intel_rapl_common.c
names each top-level zone "package-%d-die-%d" (the MSRs not package-scope and
more than one die per package), one intel-rapl:<n> zone per die, and the
package-name rule accepted only package-<n>: the host listed no package. The
rule now also accepts package-<digits>-die-<digits>, and nothing looser, so
every die zone is summed. The hardware test's oracle follows both rules.

Tests: an Intel package with two dies is two domains, each read on its own
first CPU and summed, with a one-die package beside it keeping its name; a die
whose device file is missing leaves no reader; access over the dies; an AMD
package whose CPUs list different die_ids is one domain; an Intel host with no
die_id is read per package; the name rule (package-0-die-1 yes; package-,
package-0-die-, package-0-core-0, package-0-die-1-die-2 no); a fake two-die
powercap tree summing both zones. Passing on Linux x86_64 (default, nvml,
jcp-gateway) and on macOS (the CI steps with their greps; clippy clean).

Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-11-04 21:20:55 -05:00
..
jcp-a2a Cargo: no minimum-supported-version floor, because the policy is latest stable 2026-11-03 17:42:20 -05:00
jcp-action-receipt Cargo: no minimum-supported-version floor, because the policy is latest stable 2026-11-03 17:42:20 -05:00
jcp-bridge Cargo: no minimum-supported-version floor, because the policy is latest stable 2026-11-03 17:42:20 -05:00
jcp-channel Cargo: no minimum-supported-version floor, because the policy is latest stable 2026-11-03 17:42:20 -05:00
jcp-cite Cargo: no minimum-supported-version floor, because the policy is latest stable 2026-11-03 17:42:20 -05:00
jcp-cli Cargo: no minimum-supported-version floor, because the policy is latest stable 2026-11-03 17:42:20 -05:00
jcp-conformance Cargo: no minimum-supported-version floor, because the policy is latest stable 2026-11-03 17:42:20 -05:00
jcp-efficiency Cargo: no minimum-supported-version floor, because the policy is latest stable 2026-11-03 17:42:20 -05:00
jcp-energy jcp-energy: RAPL MSR domains are per die on Intel, per package on AMD; die zones are package zones 2026-11-04 21:20:55 -05:00
jcp-flow Cargo: no minimum-supported-version floor, because the policy is latest stable 2026-11-03 17:42:20 -05:00
jcp-gateway Cargo: no minimum-supported-version floor, because the policy is latest stable 2026-11-03 17:42:20 -05:00
jcp-grant Cargo: no minimum-supported-version floor, because the policy is latest stable 2026-11-03 17:42:20 -05:00
jcp-intercept Cargo: no minimum-supported-version floor, because the policy is latest stable 2026-11-03 17:42:20 -05:00
jcp-orchestrate Cargo: no minimum-supported-version floor, because the policy is latest stable 2026-11-03 17:42:20 -05:00
jcp-policy Cargo: no minimum-supported-version floor, because the policy is latest stable 2026-11-03 17:42:20 -05:00
jcp-prompt Cargo: no minimum-supported-version floor, because the policy is latest stable 2026-11-03 17:42:20 -05:00
jcp-receipt Cargo: no minimum-supported-version floor, because the policy is latest stable 2026-11-03 17:42:20 -05:00
jcp-runtime Cargo: no minimum-supported-version floor, because the policy is latest stable 2026-11-03 17:42:20 -05:00
jcp-schema Cargo: no minimum-supported-version floor, because the policy is latest stable 2026-11-03 17:42:20 -05:00
jcp-threshold Cargo: no minimum-supported-version floor, because the policy is latest stable 2026-11-03 17:42:20 -05:00
jcp-trace Cargo: no minimum-supported-version floor, because the policy is latest stable 2026-11-03 17:42:20 -05:00
jcp-wire Cargo: no minimum-supported-version floor, because the policy is latest stable 2026-11-03 17:42:20 -05:00
jcp-x402 Cargo: no minimum-supported-version floor, because the policy is latest stable 2026-11-03 17:42:20 -05:00