One problem with the perf_events solution is that as far as I know it is not possible to find out what their "generalized events" map to without obtaining and inspecting the kernel source (and all bets are off if the source is modified and you don't know how). At least in PAPI there's a way from the interface to find out what native events underly the predefined ones.
A lot of the user/kernel issue comes down to how you use your machine. If you are a kernel developer who reboots into new kernels hourly, then putting stuff like this in the kernel is best. However if you are a user at a university or on a supercomputer where older distro kernels are used (and the kernel is updated rarely)... then you are out of luck.
For example, the new perf_events PERF_COUNT_HW_STALLED_CYCLES generalized event won't be available until possibly 2.6.40. You cannot use it unless you run that kernel or newer. And if you compile code against newer headers that have that event available and try to run it, say, on a 2.6.32 kernel... it will fail.
Wheras if you use PAPI which does the generalizing of counters in userspace, there is no backward compatability issue. The event comes with the library; a library that a regular user can install in their home directory. As long as the kernel being run provides a raw event interface for the CPU you have, it doesn't matter how old the kernel is. In fact PAPI predefined events are in theory compatible across kernel versions as well as across different _operating systems_.
Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds