lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 26 Apr 2012 12:27:11 +0200
From:	Peter Zijlstra <peterz@...radead.org>
To:	Stephane Eranian <eranian@...gle.com>
Cc:	LKML <linux-kernel@...r.kernel.org>,
	Arnaldo Carvalho de Melo <acme@...hat.com>, mingo@...e.hu,
	David Ahern <dsahern@...il.com>,
	Robert Richter <robert.richter@....com>,
	Frédéric Weisbecker <fweisbec@...il.com>,
	Jiri Olsa <jolsa@...hat.com>
Subject: Re: [BUG] perf stat: useless output for raw events with new event
 parser

On Mon, 2012-04-23 at 13:17 +0200, Stephane Eranian wrote:
> On Mon, Apr 23, 2012 at 12:48 PM, Peter Zijlstra <peterz@...radead.org> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ