Re: [PATCH] perf, x86: Enabled PEBS event to be exported in a rawformat

[Michael Ellerman]

On Tue, 2012-07-03 at 11:15 +0200, Peter Zijlstra wrote:
> On Tue, 2012-07-03 at 17:36 +1000, Michael Ellerman wrote:
> > On Fri, 2012-06-29 at 00:00 +0800, Feng Tang wrote:
> > > From: Andi Kleen <ak@xxxxxxxxxxxxxxx>
> > > 
> > > Add support for reporting PEBS records in a raw format that can
> > > be then parsed by perf script.
> > > 
> > > This is roughly similar to the existing AMD IBS support.
> > > 
> > > This is mainly for advanced users and to experiment with
> > > new usages. Widespread PEBS usages are expected to get higher
> > > level interfaces over time, like the existing "precise ip" support.
> > 
> > Hi folks,
> > 
> > Pardon if I slightly hijack this thread, but we'd like to do something
> > similar to this on powerpc.
> 
> Do expand. What does exact information does it provide?

Basically we have three registers which provide various information about
the instruction which caused an event to overflow.

The first reports the address of the instruction, the second the data
address associated with the instruction, and the third reports "other
stuff".

We use the first for SAMPLE_IP, and the second for SAMPLE_ADDR, but
currently we have no way of spitting out the third register.

There's a whole bunch of info in there. I think the most interesting are
stuff like whether and where in the pipeline the instruction stalled, or
where a load was serviced from. I'm not sure to be honest, so I've asked
the HW guys what they're most interested in.

So I can imagine us coming up with a generic sample type for "sample
other info at event overflow", but I'm struggling to see how we'd make
the content of the sample non architecture specific, or even processor
version specific.

> > I've been telling people not to use PERF_SAMPLE_RAW because it provides
> > no way for the consumer to know what data they're getting, and it's not
> > extensible in any way.
> > 
> > So is shovelling things out using PERF_SAMPLE_RAW generally acceptable
> > for "advanced usage" scenarios?
> 
> No.

OK good, at least I was right about that :)

cheers





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/