Using perf to monitor raw event counters

Question

I am trying to measure certain hardware events on a (Intel Xeon) machine with multiple (physical) processors. Specifically, I wish to know how many requests are issued for reading 'offcore' data.

I found the OFFCORE_REQUESTS hardware event in Intels documentation and it gives the event descriptor 0xB0 and for data demands, the additional mask 0x01.

Would it then be correct to tell perf to record the event 0xB1 (i.e. 0xB0 | 0x01) and to call it as:

perf record -e r0B1 ./mytestapp someargs

Or is this incorrect? Because perf report shows no output for events entered like this.

The perf documentation is rather sparse in this area, apart from a tutorial entry which does not say which event it was (though this one works for me), or how it was encoded...

Any help is greatly appreciated.

Answer 1

Ok, so I guess I figured it out.

For the the Intel machine I use, the format is as follows: <umask><eventselector> where both are hexadecimal values. The leading zeros of the umask can be dropped, but not for the event selector.

So for the event 0xB0 with the mask 0x01 I can call:

perf record -e r1B0 ./mytestapp someargs

I could not manage to find the exact parsing of it in the perf kernel code (any kernel hacker here?), but I found these sources:

• A description of the use of perf with raw events in the c't magazine 13/03 (subscription required), which describes some raw events with their description from the Intel Architecture Software Developers Manuel (Vol 3b)
• A patch on the kernel mailing list, discussing the proper way to document it. It specified that the pattern above was "... was x86 specific and imcomplete at that"
• (Updated) The man page of newer versions shows an example on Intel machines: man perf-list

Update: As pointed out in the comments (thank you!), the libpfm translator can be used to obtain the proper event descriptor. The website linked in the comments (Bojan Nikolic: How to monitor the full range of CPU performance events), discovered by user 'osgx' explains it in further detail.