Tiny Patch Gets AMD Per-Core Energy Monitoring For Linux's Perf

[phoronix]

Phoronix: Tiny Patch Gets AMD Per-Core Energy Monitoring For Linux's Perf

Exposed via Linux's very versatile perf subsystem has been per-package energy monitoring via the RAPL (Run-Time Average Power Limiting) counters. But AMD's counters also support per-core energy monitoring and now with a tiny kernel patch those sensors too will be exposed via perf...

https://www.phoronix.com/news/Linux-Perf-AMD-Per-Core-Energy

[Lbibass]

Aw sweet! So this’ll work with Ryzen 3000 models, right? Not just EPYC?

[His dad]

Doesn't make sense to me. Joule is a unit of energy. There is no time dependency.

[jaxa]

Doesn't make sense to me. Joule is a unit of energy. There is no time dependency.

8.73 looks suspiciously like Watts per core. That can go as high as 20 W, but 8.73 W would be typical for an multi-core workload.

https://www.anandtech.com/show/16214/amd-zen-3-ryzen-deep-dive-review-5950x-5900x-5800x-and-5700x-tested/8

[George99]

Doesn't make sense to me. Joule is a unit of energy. There is no time dependency.

The command as shown is accumulating energy consumption until you stop it with CRTL-C.

[microcode]

Doesn't make sense to me. Joule is a unit of energy. There is no time dependency.

This tool accumulates energy, rather than integrating for power.

[baka0815]

I'm not sure this works as intended.

Copying the test-values from Stephane Eranian:

$ perf stat --per-core -a -C0-63 -I 1000 -e power/energy-cores/,power/energy-pkg/
# time core cpus counts unit events
1.001019203 S0-D0-C0 1 1.28 Joules power/energy-cores/
1.001019203 S0-D0-C0 1 231.38 Joules power/energy-pkg/
1.001019203 S0-D0-C1 1 4,294,967,130.96 Joules power/energy-cores/
1.001019203 S0-D0-C1 1 231.38 Joules power/energy-pkg/
1.001019203 S0-D0-C2 1 4,294,967,126.23 Joules power/energy-cores/
1.001019203 S0-D0-C2 1 231.38 Joules power/energy-pkg/
1.001019203 S0-D0-C3 1 4,294,967,122.50 Joules power/energy-cores/
1.001019203 S0-D0-C3 1 231.38 Joules power/energy-pkg/
1.001019203 S0-D0-C4 1 4,294,967,129.92 Joules power/energy-cores/
1.001019203 S0-D0-C4 1 231.38 Joules power/energy-pkg/
1.001019203 S0-D0-C5 1 4,294,967,121.49 Joules power/energy-cores/
1.001019203 S0-D0-C5 1 231.39 Joules power/energy-pkg/​

This looks like bogus values returned for the energy-cores.

[polarathene]

I'm not sure this works as intended.

Copying the test-values from Stephane Eranian:

$ perf stat --per-core -a -C0-63 -I 1000 -e power/energy-cores/,power/energy-pkg/
# time core cpus counts unit events

1.001019203 S0-D0-C1 1 4,294,967,130.96 Joules power/energy-cores/

This looks like bogus values returned for the energy-cores.

The value I left in the quote if it didn't stand-out to you is a number many programmers would recognize

2^32 = 4 294 967 296

Well... close enough to that value that it's probably related to an underflow? Like if it was 0 - 196, you'd get the quoted value, because it's unsigned range, there is no negative number supported, it wraps around to the maximum value of ~4.3 billion. If it was signed, then it goes roughly 2 billion negative to 2 billion positive range for a 32-bit integer value

So quite likely a bug yep :P Probably helpful if you share / link them to that observation so they can fix that in time.

[baka0815]

polarathene
Those were numbers reported by Stephane Eranian in the patch thread, so they already know. It also doesn't matter if it's an underflow or not, those numbers are not helpful and if it's a hardware bug, the enablement just doesn't make sense. Clamping to 0 might help, but that would mean that the cores all need no energy, which is just as wrong.

So it looks to me that the implementation is not ready yet.