perf: EBNF for event syntax

RFC Lin Ming 5 participants 9 messages Mar 23, 2011 – Mar 28, 2011

lore

Share & tools

lore

Lin Ming

author

2011-03-23 03:37 UTC #0 lore raw

Hi, all

Quoted 2 lines · Peter Zijlstra

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

Peter Zijlstra

2011-03-25 11:06 UTC #1 lore raw

Quoted 11 lines · Lin Ming

Hi, all
Quoted 2 lines · Peter Zijlstra
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.

Quoted 8 lines

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.

Quoted 27 lines

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'

Quoted 8 lines

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.

Lin Ming

author

2011-03-25 13:35 UTC #2 lore raw

Quoted 23 lines · Peter Zijlstra

Quoted 11 lines · Lin Ming
Hi, all
Quoted 2 lines · Peter Zijlstra
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.
Quoted 8 lines
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:

Quoted 7 lines

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

Quoted 37 lines

Quoted 28 lines
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'
Quoted 8 lines
Modifier := ModifierSperator ModifierList
ModifierSperator := ':'
ModifierList := ModifierItem ModifierList
ModifierItem := {PreciseModifer} | kernelModifer | UserModifer | HypervisorModifer
PreciseModifer := 'p' /* Can be multiple PreciseModifers */
kernelModifer := 'k'
UserModifer := 'u'
HypervisorModifer := 'h'

Quoted 2 lines

Otherwise, very nice. Eventually we'll be able to use a parser generator for this.

Yes, bison/yacc is good for this.

Peter Zijlstra

2011-03-25 14:15 UTC #3 lore raw

Quoted 4 lines · Lin Ming

Quoted 4 lines
There was a suggestion a while back to make:
-e ev1,ev2,ev3

Quoted 8 lines

Quoted 5 lines
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.

Ulrich Drepper

2011-03-26 20:49 UTC #4 lore raw

Quoted 3 lines · Peter Zijlstra

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.

Masami Hiramatsu

2011-03-28 05:40 UTC #5 lore raw

In reply to Peter Zijlstra

Quoted 23 lines · Peter Zijlstra

Quoted 11 lines · Lin Ming
Hi, all
Quoted 2 lines · Peter Zijlstra
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.
Quoted 8 lines
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:

Quoted 7 lines

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

Signature · 4 lines

Masami HIRAMATSU
2nd Dept. Linux Technology Center
Hitachi, Ltd., Systems Development Laboratory
E-mail: [email protected]

Peter Zijlstra

2011-03-28 07:58 UTC #6 lore raw

Quoted 29 lines · Masami Hiramatsu

Quoted 28 lines · Peter Zijlstra
Quoted 11 lines · Lin Ming
Hi, all
Quoted 2 lines · Peter Zijlstra
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.
Quoted 8 lines
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.

Quoted 6 lines

Quoted 2 lines
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.

Quoted 1 line

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.

Matt Fleming

2011-03-28 08:52 UTC #7 lore raw

Quoted 3 lines · On Mon, 28 Mar 2011 09:58:10 +0200 Peter Zijlstra <[email protected]>…

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.

Masami Hiramatsu

2011-03-28 10:12 UTC #8 lore raw

In reply to Peter Zijlstra

Quoted 37 lines · Peter Zijlstra

Quoted 29 lines · Masami Hiramatsu
Quoted 28 lines · Peter Zijlstra
Quoted 11 lines · Lin Ming
Hi, all
Quoted 2 lines · Peter Zijlstra
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.
Quoted 8 lines
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.
Quoted 6 lines
Quoted 2 lines
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.)

Quoted 8 lines

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,

Signature · 4 lines

Masami HIRAMATSU
2nd Dept. Linux Technology Center
Hitachi, Ltd., Systems Development Laboratory
E-mail: [email protected]