jouleclaw-energy: RAPL reads each package's energy-status MSR where powercap lists none #618

Merged

dcharlot merged 2 commits from jouleclaw-energy/rapl-msr into main 2026-11-05 04:28:34 -05:00

Conversation 0 Commits 2 Files changed 3 +648 -36

2026-11-04

Transaction Science

jouleclaw-energy: RAPL MSR domains are per die on Intel, per package on AMD; die zones are packages ...

Linux scopes Intel's RAPL MSRs per die and AMD's and Hygon's per package
(arch/x86/events/rapl.c: "AMD/HYGON platforms have a per-PKG package energy
counter", "CLX-AP is multi-die and its RAPL MSRs are die-scope"), and the
powercap driver names a multi-die Intel package's zones package-<p>-die-<d>,
one top-level zone per die. Two consequences, both corrected here:

- The MSR fallback read each package on its first CPU, so on a multi-die Intel
  package it counted one die: an under-count, the unsafe direction at a
  ceiling. A domain is now (physical_package_id, die_id) on Intel (die 0
  where die_id is absent) and the package on AMD and Hygon, each read on its
  own lowest-numbered CPU and summed. Single-die parts are unchanged.
- The name rule accepted only package-<n>, so a multi-die host's die zones
  were not packages: no powercap package was listed. It now also accepts
  package-<n>-die-<m>, and nothing looser.

tests/rapl_hardware.rs read powercap only, so on a host with no powercap
package its oracle called the counters Unreadable while the meter, as root,
read them live through the MSRs, and the burn test had no zone to bracket.
The oracle now reads the MSRs itself where powercap lists no package, scoped
the same way, and brackets the meter's figure with outer and inner MSR reads.

On two bare-metal servers with no powercap zone (Xeon E-2278G; two Xeon
Silver 4215R sockets), the hardware tests now pass as root (oracle and meter
Live; 6.68 J and 22.07 J over a 300 ms burn, inside the oracle's MSR bracket)
and unprivileged (both Unavailable, the meter the estimator).

Tests: a two-die Intel package is two domains read on their own first CPUs
and summed; an AMD package whose CPUs list several die_ids is one domain; a
two-die powercap tree sums both die zones and not psys; the name rule's
accepts and near misses. Linux: unit and hardware tests pass (rapl,nvml);
macOS: unit tests pass, clippy clean in default, ioreport and rapl.

Co-Authored-By: Claude Opus 5.5 <[email protected]>

b9bf223411

• View at this point in history

2026-11-04 21:20:28 -05:00

Transaction Science

jouleclaw-energy: RAPL reads each package's energy-status MSR where powercap lists none ...

Some kernels ship without the powercap RAPL driver (Ubuntu without
linux-modules-extra, as on some rented bare-metal servers), so
/sys/class/powercap lists no package while the counters are there, and the
RAPL counter was unavailable on hosts that can measure. Where powercap lists
no package, the counter now reads the same counters directly: each package's
MSR_PKG_ENERGY_STATUS (0x611, Intel family 6; 0xC001029B, AMD Zen and Hygon)
through /dev/cpu/<first cpu of the package>/msr, the 32-bit count converted at
the package's own unit (bits 12:8 of the power-unit MSR), so it wraps at 2^32
counts in microjoules and resolves one count (62 uJ at 2^-14 J). A power-unit
MSR that reads zero is no counter (KVM guests read zeros). Powercap is still
preferred, and the liveness rule is unchanged: every package readable and live,
or no figure.

On two bare-metal Supermicro servers with no powercap zone, as root: a Xeon
E-2278G live, 59.8 J over 2.0 s, 29.9 W; two Xeon Silver 4215R sockets,
summed, live, 155.0 J over 2.0 s, 77.5 W. As an unprivileged user (no
CAP_SYS_RAWIO) the counter is Unavailable and the meter falls through.

Tests: fake device files (a register's bytes at its offset) cover a two-socket
host read on each package's first CPU, the 32-bit wrap, AMD's registers, a zero
unit, an unknown CPU, a missing device, powercap preferred, and the production
probe over MSR packages. Unit tests pass on Linux and macOS; clippy is clean on
macOS (default, ioreport, rapl).

Co-Authored-By: Claude Opus 5.5 <[email protected]>

32d27b06fd

• View at this point in history

2026-11-04 14:39:19 -05:00