Re: [PATCH 08/12] perf: export some syscall metadata

[Frederic Weisbecker <fweisbec@gmail.com>]

On Thu, Feb 25, 2010 at 12:51:35AM -0600, Tom Zanussi wrote:
> On Thu, 2010-02-25 at 03:43 +0100, Frederic Weisbecker wrote:
> > On Wed, Feb 24, 2010 at 12:00:43AM -0600, Tom Zanussi wrote:
> > > Re event injection - I don't know that much about it, but if it can be
> > > used for this, could it also be applied to the rest of the trace and
> > > header data too?  If so, that would enable 'live mode' tracing.  I
> > > already have a working prototype that does it by converting all those
> > > things into synthesized pseudo-events, but it would be nicer to use the
> > > event injection framework instead, if I understand it correctly...
> > 
> > 
> > I'm not sure what you mean about live mode tracing. But yeah this
> > about synthetizing pseudo-events. The purpose is to catchup with
> > "past events" or "dead events".
> > 
> > The first trial was for lock_init events. Lock init events send
> > the address of the lock plus its name, so that subsequent lock
> > events (lock acquire, lock_release) can just send the address
> > in the event and not the name which can then be retrieved
> > from past lock_init events.
> > 
> > One problem though: when we enable the lock_init event, we
> > only catch the new locks created. So we need the previously
> > registered locks. There may be severals ways to do that: using
> > a perf ioctl or so, it's still in discussion.
> > 
> > But then for syscalls we would have a kind of dead events
> > catching up by asking the kernel to send us the nr:name
> > pairs.
> > 
> 
> By 'live mode' tracing, I mean feeding the trace stream continuously to
> the script rather than writing it to disk and then later running the
> script on the file data.  Basically something like this:
> 
> $ perf record -e event1 -e event2 -o - | perf trace -s myscript.py -i -
> 
> where the output of perf record is streamed to stdout and piped to the
> the script, which continuously reads and processes events from stdin,
> until the user hits ctrl-c or the script detects some arbitrary pattern
> or condition in the trace stream and stops and prints out the results.
> 
> This would allow a whole new class of use cases e.g. you could easily
> convert any of the current scripts into 'top' versions by adding a timer
> that would display and clear the current results on each tick, say every
> 5 seconds.  Or just actively scan the trace data for some arbitrarily
> complex condition, while also saving the last n trace records and
> dumping them when the condition is found, etc...
> 
> The main obstacle to doing this with the current perf is the header
> data, which in my prototype I've converted into 4 pseudo events - attrs,
> event_types, tracing_data and build_ids, basically getting rid of
> everything than uses a seek, so I can shove it all over a pipe.
> 
> It does seem to me that event injection could be used for this instead
> e.g. similar to the case of lock_init/subsequent lock events, for the
> script to be able to process an event it needs the event information
> contained in the trace_data, which could be sent as an injected event,
> for that subsequent event.  My prototype just sends it all as one huge
> event right now, but if it were broken down into individual events, that
> would also allow new events to be added and removed dynamically.  So in
> addition to 'live mode' we could add 'dynamic' mode as well. :-)
> 
> So yeah, it looks like it would be useful for the syscall names, but
> hopefully much more than that...


Ok, I see what you mean by live mode now.
But I  don't understand why you'd need the injection for that.
If you start a recording, even if it is launched in live mode, you
can parse the necessary format information before, right?