[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1301299090.4859.6.camel@twins>
Date: Mon, 28 Mar 2011 09:58:10 +0200
From: Peter Zijlstra <a.p.zijlstra@...llo.nl>
To: Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>
Cc: Lin Ming <ming.m.lin@...el.com>, mingo@...e.hu,
Arnaldo Carvalho de Melo <acme@...stprotocols.net>,
Frederic Weisbecker <fweisbec@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
Paul Mackerras <paulus@...ba.org>,
Stephane Eranian <eranian@...gle.com>,
Steven Rostedt <rostedt@...dmis.org>,
Thomas Gleixner <tglx@...utronix.de>,
Hitoshi Mitake <mitake@....info.waseda.ac.jp>,
Corey Ashford <cjashfor@...ux.vnet.ibm.com>,
Matt Fleming <matt@...sole-pimps.org>,
"2nddept-manager@....hitachi.co.jp"
<2nddept-manager@....hitachi.co.jp>
Subject: Re: [RFC] perf: EBNF for event syntax
On Mon, 2011-03-28 at 14:40 +0900, Masami Hiramatsu wrote:
> (2011/03/25 20:07), Peter Zijlstra wrote:
> > On Wed, 2011-03-23 at 11:36 +0800, Lin Ming wrote:
> >> Hi, all
> >>
> >> On Thu, Mar 17, 2011 at 2:02 AM, Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
> >>> How about we start writing proper EBNF syntax rules for this stuff, its
> >>> getting seriously out of hand.
> >> http://marc.info/?l=linux-kernel&m=130029871318866&w=2
> >>
> >> As Peter suggested, I wrote a simple EBNF for event syntax, as below.
> >> My first plan is to pass in extra config value for some events,
> >> for example, offcore response and load latency.
> >>
> >> perf record -e r100b(0004):p
> >>
> >> As above, the extra config value 0004 is passed in the parentheses.
> >>
> >> The EBNF
> >> ========
> >>
> >> EventList := Event [',' EventList]
> >
> > There was a suggestion a while back to make:
> >
> > -e ev1,ev2,ev3
> >
> > create an event group with ev2 and ev3 siblings of ev1, and have
> > multiple -e instances create separate counters.
> >
> > The problem is that its not backwards compatible, but something like
> > that would still be very nice to have.
>
> I doubt that we really need to define those events are
> grouped at recording time, because group(event ratio)
> analysis must be done at analysis time(report etc.)
Uhm, grouping isn't at all related to event ratios, you can do event
ratios just fine without groups - there's some stronger correlation when
you do ratios with groups, but since its all statistics anyway, you can
get that same extra correlation by simply running longer too.
Groups are most useful in measuring events on another base, which is
basically mandatory if your primary event doesn't have sampling support
itself.
> IMHO, it should be done with a separate option instead of -e.
Possibly, but it would get pretty much the same syntax which might or
might not confuse people.
--
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