If we are sampling multiple events we need the id in each sample so we can
differentiate between them in a perf data file.
Signed-off-by: Anton Blanchard <[email protected]>
---
Index: linux.trees.git/tools/perf/builtin-record.c
===================================================================
--- linux.trees.git.orig/tools/perf/builtin-record.c 2009-10-21 14:58:33.000000000 +1100
+++ linux.trees.git/tools/perf/builtin-record.c 2009-10-21 17:12:33.000000000 +1100
@@ -413,6 +413,9 @@ static void create_counter(int counter,
attr->sample_type |= PERF_SAMPLE_CPU;
}
+ if (nr_counters > 1)
+ attr->sample_type |= PERF_SAMPLE_ID;
+
attr->mmap = track;
attr->comm = track;
attr->inherit = (cpu < 0) && inherit;
* Anton Blanchard <[email protected]> wrote:
> If we are sampling multiple events we need the id in each sample so we
> can differentiate between them in a perf data file.
Wondering, what are you (or will you be) using this for?
Ingo
Hi Ingo,
> > If we are sampling multiple events we need the id in each sample so we
> > can differentiate between them in a perf data file.
>
> Wondering, what are you (or will you be) using this for?
I put together a simple python library for parsing perf.data files:
http://ozlabs.org/~anton/junkcode/perf_event.py
An example of using it is here:
http://ozlabs.org/~anton/junkcode/perf_event_example.py
Only tested on powerpc so far, but it should work on x86. It's still
missing bits but it has been useful for finding some corner cases in
perf_event. It should also make it easy to post process complex profiles with
multiple events in them.
One problem this has just found though, is with PERF_EVENT_SAMPLE:
# FIXME: If sampling multiple events we have an issue
# here. Since the SAMPLE_ID is not the first optional field
# it might be impossible to differentiate between
# events since the SAMPLE_ID field would be at different
# offsets. For now we assume all events use the same
# set of optional fields.
eventnr = 0
self.event = sample_event(eventbuf,
self.header.attrs[eventnr].sample_type)
It seems like the API allows us to specify different sample options for
different events, but since the ID isnt the first option it could end up
in different places in different events, making it difficult (if not
impossible in some cases) to tag events correctly.
Anton
* Anton Blanchard <[email protected]> wrote:
>
> Hi Ingo,
>
> > > If we are sampling multiple events we need the id in each sample so we
> > > can differentiate between them in a perf data file.
> >
> > Wondering, what are you (or will you be) using this for?
>
> I put together a simple python library for parsing perf.data files:
>
> http://ozlabs.org/~anton/junkcode/perf_event.py
>
> An example of using it is here:
>
> http://ozlabs.org/~anton/junkcode/perf_event_example.py
>
> Only tested on powerpc so far, but it should work on x86. It's still
> missing bits but it has been useful for finding some corner cases in
> perf_event. It should also make it easy to post process complex
> profiles with multiple events in them.
Ah, cool!
Note, there's a related development: we are working on script extensions
to perf, in a built-in way. It can be found in this patch series from
Tom on lkml:
[RFC][PATCH 0/9] perf trace: support for general-purpose scripting
Tom started with Perl support - Python could be another script engine to
add.
Now, your perf_event_example.py library goes deeper and exposes the
perf.data itself as an independent codepath. I _think_ Tom's approach
gives us a bit of an extra value by allowing us to tweak the environment
of scripts with each perf version - i.e. we can iterate the perf.data
format in the future without breaking scripts.
We are not ready yet to declare perf.data an ABI, and there's a few
changes in tip:perf/* that might break the python library.
Also, as your fix demonstrates it, there's extra value in going
ab-initio as well. Just wanted to mention the scripting engine work to
couple perf with scriptlets, in case you find it interesting. We could
easily do both.
> One problem this has just found though, is with PERF_EVENT_SAMPLE:
>
> # FIXME: If sampling multiple events we have an issue
> # here. Since the SAMPLE_ID is not the first optional field
> # it might be impossible to differentiate between
> # events since the SAMPLE_ID field would be at different
> # offsets. For now we assume all events use the same
> # set of optional fields.
> eventnr = 0
> self.event = sample_event(eventbuf,
> self.header.attrs[eventnr].sample_type)
>
> It seems like the API allows us to specify different sample options
> for different events, but since the ID isnt the first option it could
> end up in different places in different events, making it difficult
> (if not impossible in some cases) to tag events correctly.
Could we fix this bug at the kernel level somehow, to imply SAMPLE_ID
automatically? Producing a stream of data that cannot be decoded in some
cases does not look smart.
Ingo