[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20111221161613.GA1659@m.brq.redhat.com>
Date: Wed, 21 Dec 2011 17:16:13 +0100
From: Jiri Olsa <jolsa@...hat.com>
To: Peter Zijlstra <peterz@...radead.org>, acme@...hat.com
Cc: mingo@...e.hu, paulus@...ba.org, cjashfor@...ux.vnet.ibm.com,
linux-kernel@...r.kernel.org
Subject: new syntax for perf event
On Tue, Dec 20, 2011 at 12:39:21PM +0100, Peter Zijlstra wrote:
> On Tue, 2011-12-20 at 12:30 +0100, Peter Zijlstra wrote:
> > event config-0:7
> > umask config-8:15
> > usr config-16
> > os config-17
> > edge config-18
> > any config-21
> > inv config-23
> > cmask config-24:31
> >
> > nhm-dmnd_data_rd config1-0
> > nhm-dmnd_rfo config1-1
> > nhm-dmnd_ifetch config1-2
> > ...
> >
> > (the real syntax will likely be a little more complex in order to be
> > able to express the various other architectures their raw input format).
>
> for instance AMD would need:
>
> event config-0:7,32-35
> guest config-40
> host config-41
>
> (assuming you read that as a mask from LSB to MSB)
>
> And I still haven't actually read how the P4 works so I can't help out
> there.
ok first try ;) description + grammar attached
- event has a general format:
pmu/event_def[:modifier] [ ',' pmu/event_def[:modifier] ] ...
where event_def depends on the chosen pmu:
'cpu' 'tracepoint' 'breakpoint'
- to keep some of the old interface, symbolic and cache events stays,
since they are recognizable by keywords (event_symbol, event_cache)
- raw events are defined with the help of event keywords like:
cpu/raw,config=1,config1=0,config2=0
cpu/hw,config=1,config1=0
* first symbol after '/' defines the type: raw/hw/cache
which match PERF_TYPE_RAW/PERF_TYPE_HARDWARE/PERF_TYPE_HW_CACHE
* the rest consists assignments for 'config/config1/config1' keywords
that match with the perf_event_attr:config/config1/config values
(possibly extended once we have sysfs events representation)
- tracepoint events are defined like:
tracepoint/system:tracepoint
where tracepoint could contain '*?'
- breakpoint events are defined like:
breakpoint/addr:type
- each event could be followed by modifier definition
- I think pmu names should match registered pmu names,
but we could make some shortcuts so we dont need to type 'tracepoint/',
but just 'tp/' or smth..
- as for tracepoints it looks like the old format does not clash with the new one
and we could add shortcut (omit the 'tracepoint/') like:
event: event_tracepoint
- not sure I should include 'software' pmu, as it seems to covered by
event_symbol events
thanks for comments,
jirka
grammar
-------
events:
event_mod ',' event_mod | event_mod
event_mod:
event | event ':' modifier
event:
event_symbol |
event_cache |
'cpu' '/' event_cpu |
'tracepoint' '/' event_tracepoint
'breakpoint' '/' event_breakpoint
event_symbol:
cpu-cycles|cycles
stalled-cycles-frontend|idle-cycles-frontend
stalled-cycles-backend|idle-cycles-backend
instructions
cache-references
cache-misses
branch-instructions|branches
branch-misses
bus-cycles
cpu-clock
task-clock
page-faults|faults
minor-faults
major-faults
context-switches|cs
cpu-migrations|migrations
alignment-faults
emulation-faults
event_cache:
cache_type
cache_type '-' cache_result_op
cache_type '-' cache_result_op '-' cache_result_op
cache_type:
L1-dcache|l1-d|l1d|L1-data
L1-icache|l1-i|l1i|L1-instruction
LLC|L2
dTLB|d-tlb|Data-TLB
iTLB|i-tlb|Instruction-TLB
branch|branches|bpu|btb|bpc
node
cache_result_op:
load|loads|read
store|stores|write
prefetch|prefetches
speculative-read|speculative-load
refs|Reference|ops|access
misses|miss
event_cpu:
'raw' ',' event_cpu_def
'hw' ',' event_cpu_def
'cache' ',' event_cpu_def
event_cpu_def:
event_cpu_ass ',' event_cpu_ass |
event_cpu_ass
event_cpu_ass:
event_cpu_elem '=' value
event_cpu_elem:
'config' | 'config1' | 'config2'
event_tracepoint:
system ':' tracepoint
event_breakpoint:
addr ':' type
modifier:
[ukhp]{1,4}
--
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