Re: [BUG] perf stat: useless output for raw events with new eventparser

[Peter Zijlstra]

On Mon, 2012-04-23 at 13:17 +0200, Stephane Eranian wrote:
> On Mon, Apr 23, 2012 at 12:48 PM, Peter Zijlstra <peterz@xxxxxxxxxxxxx> wrote:
> > On Mon, 2012-04-23 at 12:45 +0200, Stephane Eranian wrote:
> >> Hi,
> >>
> >> With the new event parser, one can express raw events field by field:
> >>
> >> $ perf stat -e cpu/event=0x3c,umask=0x0/,cpu/event=0xc5,umask=0x0/ noploop 1
> >>
> >> The problem with this is that the output of perf stat becomes useless:
> >>
> >> $ perf stat -e cpu/event=0x3c,umask=0x0/,cpu/event=0xc5,umask=0x0/ noploop 1
> >> noploop for 1 seconds
> >>
> >>  Performance counter stats for 'noploop 1':
> >>
> >>         2395038678 pmu
> >>             10787 pmu
> >>                        ^^^^^^
> >>        1.000802603 seconds time elapsed
> >
> > Yeah, I already complained about that.. Jolsa proposed adding a name=
> > parameter so you could explicitly name your events. I think I've seen a
> > patch adding that, but can't atm seem to locate it.
> >
> If the proposed solution is to add a pseudo field called "name", then I don't
> see the point of this new parser compared to directly using my libpfm4
> library which already allows:
> 
>  perf stat -e inst_retired:any,wsm_unc:unc_cycles:u ...
> And
>  perf record -e instr_retired:period=200000,cpu_clk_unhalted:freq=100 ...
> 
> If you have to make up names, you might as well, use the actual PMU
> event names, but if you do so, why would you have to bother breaking
> down the encoding into fields?

I'd like to use the event names, but really, when you do:

 cpu/event=instructions_retired,inv,cmask=16/

is it still instructions_retired?

In SFO we spoke about exporting those event tables you have in libpfm4
in some structured file format so that we both might use them, the
primary difficulty in that (IIRC) was the umask constraints per event.

I'm not too overly bothered by people specifying wrong events (at some
point they really had better know wth they're doing anyway), so can we
start with something that mostly works?

I've already spoken with Jiri about adding this before all this parser
stuff got implemented, so it should all be quite possible to add.

Furthermore, once we have a common format, we could even ask Intel/AMD
(and other vendors) to provide their data in this format.


--
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/