Raw events and the perf ABI [LWN.net]

Raw events and the perf ABI

Posted May 5, 2011 13:44 UTC (Thu) by ejr (subscriber, #51652)
Parent article: Raw events and the perf ABI

It's worth noting that Dr. Weaver points out perfctr's low overhead and latency, and Mr. Gleixner counters by bringing up perfmon. They're different beasts. The former worked wonderfully for us users over many years and still has a decent user base (possibly the largest if you count by node rather than by user).

The poor PAPI folks are trying their best to keep us users productive, but I'm still running into problems that never existed before like artificially limited numbers of counters.

But, hey, NIH, "there are no users," and all that.

to post comments

Raw events and the perf ABI

Posted May 5, 2011 13:47 UTC (Thu) by ejr (subscriber, #51652) [Link] (2 responses)

AUGH! And now I find this: http://article.gmane.org/gmane.linux.kernel/1132912

Well, at least now I know why some of my performance results have been so utterly mystifying. Wow. Think I'll go back to perfctr as best I can.

Raw events and the perf ABI

Posted May 5, 2011 18:52 UTC (Thu) by deater (subscriber, #11746) [Link] (1 responses)

To be fair, PAPI changes predefined event definitions from time to time too.

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_.

Raw events and the perf ABI

Posted May 5, 2011 20:19 UTC (Thu) by ejr (subscriber, #51652) [Link]

Exactly. It's about a month turn-around between possible kernel-level fixes on the relevant small-ish machine here. Other places (e.g. NERSC & ORNL), well, forget it. Rebooting a 19k node machine isn't taken lightly. Not supporting raw access to the different levels makes using performance counters *more* difficult, not less. And calling out-of-tree userspace interfaces non-existent is dishonest.