Hi, all
On Thu, Mar 17, 2011 at 2:02 AM, Peter Zijlstra <[email protected]> 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]
Event := HardwareEvent |
RawEvent |
SoftwareEvent |
TracepointEvent |
HardwareBreakpointEvent
HardwareEvent := HardwareEventName [ExtraConfig] [Modifer]
HardwareEventName := 'cpu-cycles' | 'cycles' | 'instructions' /* and so on ...*/
ExtraConfig := '(' ConfigValue [',' ConfigValue] ')'
ConfigValue := HexNumber
RawEvent := RawSeperator RawCode [ExtraConfig] [Modifer]
RawSeperator := 'r'
RawCode := HexNumber
SoftwareEvent := SoftwareEventName
SoftwareEventName := 'cpu-clock' | 'task-clock' | 'faults' /* and so on ...*/
TracepointEvent := SubsystemName ':' TracepointName
SubsystemName := /* All AsciiString except the pre-defined hardware/software/cache events name and BreakpointSeparator */
TracepointName := '*' | AsciiString
HardwareBreakpointEvent := BreakpointSeparator BreakpointAddress [':' AccessType]
BreakpointSeparator := 'mem:'
BreakpointAddress := HexNumber
AccessType := 'r' | 'w' | 'x'
Modifier := ModifierSperator ModifierList
ModifierSperator := ':'
ModifierList := ModifierItem ModifierList
ModifierItem := {PreciseModifer} | kernelModifer | UserModifer | HypervisorModifer
PreciseModifer := 'p' /* Can be multiple PreciseModifers */
kernelModifer := 'k'
UserModifer := 'u'
HypervisorModifer := 'h'
Some valid examples
===================
Hardware events with modifiers,
cycles:pk,instructions:u
Raw event with extra config values and/or modifiers,
r0110(40A0):pu
r0110(40A0,40A1):k
Software event,
cpu-clock,faults
Hardware breakpoint events:
mem:400346
mem:800A03:w
Some invalid examples
=====================
r0110(40A0,40A1,40A2), invalid, only 2 extra config values are allowed
cpu-clock:p, invalid, software event does not have precise modifier
Any comments?
Thanks,
Lin Ming
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 <[email protected]> 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.
> Event := HardwareEvent |
> RawEvent |
> SoftwareEvent |
> TracepointEvent |
> HardwareBreakpointEvent
>
> HardwareEvent := HardwareEventName [ExtraConfig] [Modifer]
> HardwareEventName := 'cpu-cycles' | 'cycles' | 'instructions' /* and so on ...*/
> ExtraConfig := '(' ConfigValue [',' ConfigValue] ')'
> ConfigValue := HexNumber
>
> RawEvent := RawSeperator RawCode [ExtraConfig] [Modifer]
> RawSeperator := 'r'
> RawCode := HexNumber
>
> SoftwareEvent := SoftwareEventName
> SoftwareEventName := 'cpu-clock' | 'task-clock' | 'faults' /* and so on ...*/
>
> TracepointEvent := SubsystemName ':' TracepointName
> SubsystemName := /* All AsciiString except the pre-defined hardware/software/cache events name and BreakpointSeparator */
> TracepointName := '*' | AsciiString
>
> HardwareBreakpointEvent := BreakpointSeparator BreakpointAddress [':' AccessType]
> BreakpointSeparator := 'mem:'
> BreakpointAddress := HexNumber
> AccessType := 'r' | 'w' | 'x'
>
> Modifier := ModifierSperator ModifierList
> ModifierSperator := ':'
> ModifierList := ModifierItem ModifierList
> ModifierItem := {PreciseModifer} | kernelModifer | UserModifer | HypervisorModifer
> PreciseModifer := 'p' /* Can be multiple PreciseModifers */
> kernelModifer := 'k'
> UserModifer := 'u'
> HypervisorModifer := 'h'
Otherwise, very nice. Eventually we'll be able to use a parser generator
for this.
On Fri, 2011-03-25 at 19:07 +0800, 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 <[email protected]> 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.
Currently, it means a list of independent events, right?
>
> > Event := HardwareEvent |
> > RawEvent |
> > SoftwareEvent |
> > TracepointEvent |
> > HardwareBreakpointEvent
> >
> > HardwareEvent := HardwareEventName [ExtraConfig] [Modifer]
> > HardwareEventName := 'cpu-cycles' | 'cycles' | 'instructions' /* and so on ...*/
> > ExtraConfig := '(' ConfigValue [',' ConfigValue] ')'
> > ConfigValue := HexNumber
> >
> > RawEvent := RawSeperator RawCode [ExtraConfig] [Modifer]
> > RawSeperator := 'r'
> > RawCode := HexNumber
> >
> > SoftwareEvent := SoftwareEventName
> > SoftwareEventName := 'cpu-clock' | 'task-clock' | 'faults' /* and so on ...*/
> >
> > TracepointEvent := SubsystemName ':' TracepointName
> > SubsystemName := /* All AsciiString except the pre-defined hardware/software/cache events name and BreakpointSeparator */
> > TracepointName := '*' | AsciiString
> >
> > HardwareBreakpointEvent := BreakpointSeparator BreakpointAddress [':' AccessType]
> > BreakpointSeparator := 'mem:'
> > BreakpointAddress := HexNumber
> > AccessType := 'r' | 'w' | 'x'
> >
> > Modifier := ModifierSperator ModifierList
> > ModifierSperator := ':'
> > ModifierList := ModifierItem ModifierList
> > ModifierItem := {PreciseModifer} | kernelModifer | UserModifer | HypervisorModifer
> > PreciseModifer := 'p' /* Can be multiple PreciseModifers */
> > kernelModifer := 'k'
> > UserModifer := 'u'
> > HypervisorModifer := 'h'
>
> Otherwise, very nice. Eventually we'll be able to use a parser generator
> for this.
Yes, bison/yacc is good for this.
On Fri, 2011-03-25 at 21:35 +0800, Lin Ming wrote:
> > 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.
>
> Currently, it means a list of independent events, right?
>
Right, and as said changing this would create some backward compat
problems so I'm not sure its the best proposal, just wanted to raise the
issue that such functionality would be nice.
On Fri, Mar 25, 2011 at 10:17, Peter Zijlstra <[email protected]> wrote:
> Right, and as said changing this would create some backward compat
> problems so I'm not sure its the best proposal, just wanted to raise the
> issue that such functionality would be nice.
Not only nice, it's pretty much a requirement. Most useful statistics
come in the form of ratios. Collecting the values for ratios much
happen concurrently. Currently perf isn't better than oprofile in
this respect. One has to start perf separately for each ratio.
(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 <[email protected]> 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.)
IMHO, it should be done with a separate option instead of -e.
Thank you,
--
Masami HIRAMATSU
2nd Dept. Linux Technology Center
Hitachi, Ltd., Systems Development Laboratory
E-mail: [email protected]
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 <[email protected]> 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.
On Mon, 28 Mar 2011 09:58:10 +0200
Peter Zijlstra <[email protected]> wrote:
> Groups are most useful in measuring events on another base, which is
> basically mandatory if your primary event doesn't have sampling
> support itself.
Just FYI...
When I was looking at group event support for SH (because the hardware
doesn't have sampling support) I was trying to avoid the user being
required to setup the groups on the command-line, e.g. I wrote it so
that the group event creation was all done "behind the scenes".
For those architectures/platforms that are missing sampling support I
still think that group event creation should be as invisible as
possible.
(2011/03/28 16:58), Peter Zijlstra wrote:
> 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 <[email protected]> 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.
Ah, OK, there are some arch/events don't have a sampling mode.
If I understand it correctly, how about below syntax?
-e (ev2,ev3)/ev1
This create an event group with ev2 and ev3 siblings of ev1 (and
ev1 gives sampling base).
Thank you,
--
Masami HIRAMATSU
2nd Dept. Linux Technology Center
Hitachi, Ltd., Systems Development Laboratory
E-mail: [email protected]