Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for Alder Lake #216

Closed
cvonelm opened this issue Aug 11, 2022 · 0 comments · Fixed by #217
Closed

Support for Alder Lake #216

cvonelm opened this issue Aug 11, 2022 · 0 comments · Fixed by #217
Assignees

Comments

@cvonelm
Copy link
Member

cvonelm commented Aug 11, 2022

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:

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 availiblity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants