Software Tuning, Performance Optimization & Platform Monitoring
Discussion regarding monitoring and software tuning methodologies, Performance Monitoring Unit (PMU) of Intel microprocessors, and platform updating.

reading power via performance counters

aozcan
New Contributor I
550 Views

Hi,

 

I have written a trivial application that reads PMA value of cores in Skylake microarchitectures. I  programmed performance counters according to the uncore performance monitoring manual.

 

Manual link: https://kib.kiev.ua/x86docs/Intel/PerfMon/336274-001.pdf

 

Relevant page:

aozcan_0-1658314021006.png

 

I programmed it so that I would read GV value.

 

Here is the code:

 

https://github.com/ozcanay/pma_core

 

Note that code is not portable, it assumes that you have 18 CHAs.

 

You can build the code with:

 

g++ main.cpp -lpthread

 

And then run it with SUDO PRIVILEGES via:

 

sudo ./a.out <INSERT CORE NUMBER HERE>

 

Example: ./a.out 1

 

Application fires up a thread and binds it to core 1 in this case. Before keeping the core busy by incrementing a variable in a tight loop, it reads power value of all CHAs. Power value of all CHAs is read again after the incrementing phase is done. The CHA that has the most difference between before and after power values is expected to be co-located with the core the thread is bound to. This was the overview of the application. 

 

The thing is this code was working correctly 6 months ago. You can see the correct example output in github repo. Now that I tried to run the application again, except for CHA0 and CHA16 I am just reading values of 0 from all CHAs. Before and after values of CHA0 and CHA16 are non-zero but same.  So, my question is: Is there any possible reasons that would prevent me from reading power values now?

 

Thanks and best regards.

 

0 Kudos
1 Reply
McCalpinJohn
Honored Contributor III
535 Views

I don't see anything resembling documentation for the GV sub-event of the CHA CORE_PMA event, so it is hard to tell what it is supposed to mean. The other sub-events are C-state-related, which means that BIOS options can change the behavior.

0 Kudos
Reply