lkml.org 
[lkml]   [2009]   [Oct]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] perf record: Enable PERF_SAMPLE_ID when sampling multiple events

* Anton Blanchard <anton@samba.org> 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


\
 
 \ /
  Last update: 2009-10-23 08:21    [W:0.057 / U:0.412 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site