You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
See #213 for the some more info on how this issue came to be
Alder lake is hybrid architecture, which consists of powerful P-Cores and energy saving E-Cores.
Our current code assumes that every core is capable of opening every event, which isn't the case here.
There are generally two types of events available on Alder Lake, if viewed from perf: Events that are available everywhere and Events that are available on just one core type.
Event available everywhere
Those events basically work like you would expect it from older Intel architectures. If I'm interpreting the documentation correctly, then there are actually no magic "everywhere" events, the kernel is just being smart about opening the right type of event for the right core. The extent of this magic of course remains to be tested, but our Alder Lake system is for reasons of being new and shiny seldomly available for such basic test work.
Events that are available one only one core type
Some PMU events are only available on one of the two types of cores. Generally, the cpu_atom PMU contains the E-Core events and the cpu_core PMU contains the P-Core events, but that is not something I would not rely on.
Rather, a new file has been added to the PMU directory which you can get the range of cores with support for the PMU from:
Parsing this it should be easy to test if the event is really available by testing if the event can be opened on one of the cores in the range.
In system monitoring readers for that event would only be created for cores in that range.
As far as I know, process monitoring already works out the box, with the caveat that as long as a process is scheduled on a core without support for that event, the event will read 0. Correct pinning is left as an exercise to the user in that case. --list-events would be needed to modified to show core availiblity
The text was updated successfully, but these errors were encountered:
See #213 for the some more info on how this issue came to be
Alder lake is hybrid architecture, which consists of powerful P-Cores and energy saving E-Cores.
Our current code assumes that every core is capable of opening every event, which isn't the case here.
There are generally two types of events available on Alder Lake, if viewed from perf: Events that are available everywhere and Events that are available on just one core type.
Event available everywhere
Those events basically work like you would expect it from older Intel architectures. If I'm interpreting the documentation correctly, then there are actually no magic "everywhere" events, the kernel is just being smart about opening the right type of event for the right core. The extent of this magic of course remains to be tested, but our Alder Lake system is for reasons of being new and shiny seldomly available for such basic test work.
Events that are available one only one core type
Some PMU events are only available on one of the two types of cores. Generally, the
cpu_atom
PMU contains the E-Core events and thecpu_core
PMU contains the P-Core events, but that is not something I would not rely on.Rather, a new file has been added to the PMU directory which you can get the range of cores with support for the PMU from:
cvonelm@kallisto:~$ cat /sys/devices/cpu_core/cpus 0-15
Parsing this it should be easy to test if the event is really available by testing if the event can be opened on one of the cores in the range.
In system monitoring readers for that event would only be created for cores in that range.
As far as I know, process monitoring already works out the box, with the caveat that as long as a process is scheduled on a core without support for that event, the event will read 0. Correct pinning is left as an exercise to the user in that case.
--list-events
would be needed to modified to show core availiblityThe text was updated successfully, but these errors were encountered: