Message-Id: <1267080695.6611.188.camel@tropicana>
Date:	Thu, 25 Feb 2010 00:51:35 -0600
From:	Tom Zanussi <tzanussi@...il.com>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	linux-kernel@...r.kernel.org, mingo@...e.hu, rostedt@...dmis.org,
	k-keiichi@...jp.nec.com
Subject: Re: [PATCH 08/12] perf: export some syscall metadata

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




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