perf: Use libpfm4 and Linux style event strings
authorBarret Rhoden <brho@cs.berkeley.edu>
Thu, 19 May 2016 20:04:18 +0000 (16:04 -0400)
committerBarret Rhoden <brho@cs.berkeley.edu>
Thu, 16 Jun 2016 15:48:36 +0000 (11:48 -0400)
commitdf8800880c03c7bc18980ba72e845b3b9b343a35
treeac75714548c335000c7a2ae22aebac0325695f1a
parenta9584d8f5e15a137b5e30067938c1b38c17b0d13
perf: Use libpfm4 and Linux style event strings

We had been using a custom event string, which was incompatible with both
Linux's perf and libpfm4.

Now, we accept any libpfm4 string, and barring that, we'll use perf-style
raw codes.  We accept pfm4-like modifiers, such as :u and :k.  Unlike perf,
we require that each modifier/token is separated by :.

So this works:

-e inst_retired:u:k

But this doesn't:
-e inst_retired:uk

That's actually libpfm4, not us.  I do the same thing for the raw codes
though, since we might as well be consistent (and simple).

In the process, I also fixed a couple issues with event specification.

Many events from libpfm4 are more than 8 bits long.  The old code assumed
that the event was 8 bits and the mask was 8 bits.  That meant that we
could submit events like 0x13c properly (you'd have to write it as
0x3c:0x01, even though perf list told your 0x13c).  Surprise!  Now we allow
longer event selectors, where the upper bits are the mask.  That's just
what libpfm4 expects, and really it is how the hardware (and OS interface)
are programmed.

The other issue is pseudo-encoded events.  On most Intel machines, libpfm4
returns the event 0x300 for unhalted_reference_cycles.  That's not a real
code, and will silently fail.  It needs to be the fixed counter 2.  Linux
knows this, but we weren't interpreting it.  Without these changes,
attempts to use unhalted_reference_cycles would simply return 0 for the
perf counters.

Signed-off-by: Barret Rhoden <brho@cs.berkeley.edu>
tools/profile/perf/perf_core.c
tools/profile/perf/perf_core.h