From: "Frank Ch. Eigler" <fche@redhat.com>
To: "Frédéric Weisbecker" <fweisbec@gmail.com>
Cc: Steven Rostedt <rostedt@goodmis.org>, Ingo Molnar <mingo@elte.hu>,
linux-kernel@vger.kernel.org, systemtap@sources.redhat.com
Subject: Re: [PATCH 5/5] tracing/ftrace: Introduce the big kernel lock tracer
Date: Fri, 24 Oct 2008 15:29:49 -0400 [thread overview]
Message-ID: <20081024192949.GC8210@redhat.com> (raw)
In-Reply-To: <c62985530810240826l2e025e94i51fdfd0fc70b0449@mail.gmail.com>
Hi -
On Fri, Oct 24, 2008 at 05:26:53PM +0200, Frédéric Weisbecker wrote:
> [...]
> Actually what I thought is a style like this (Python like):
>
> probe = Systemtap.probeFunc("lock_kernel")
> probe.captureUtime("utime"))
> probe.captureBacktrace("trace")
> probe.trace()
>
> For an obvious set of batch work like that, that could be possible,
> perhaps even easy to implement an Api...
> When the object calls trace(), the userspace Systemtap analyse the list
> of work to do and then translate into commands in kernel space.
There comes a point not too far beyond this example where one may want
to capture functions of values; filter; perform loops/conditionals;
refer to variables/arrays. Coding that logic this way would be so
clumsy as to take away any charm of working in python.
> And the script could wait for events and then do its own processing
> with the captured events (do some operations on delays, on output....).
>
> for event in probe.getEvent(): #blocking
> print event["utime"]
> trace = event["trace"] #Systemtap.trace object with specific
> fields and a default string repr
> print trace
>
> It would be interpreted by Python itself [...]
This is too gets impractical. If the only event handler code is
general python, it can't practically be executed within the kernel.
So we're then talking about a python script consuming trace data
streamed in. We lose:
- capability to take immediate action upon event occurrence
- any claim to good performance (~microsecond event handling)
- the natural coupling between events and their handlers
- the ability to statically analyze the entire instrumentation,
to optimize locking, data encoding
Now, one may imagine using this sort of thing as a *wrapper* around
plain systemtap: where the python libraries generate stylized
systemtap code that emits data in a form that the later "getEvent"
routine can decode again and act upon.
Several people have written shell, perl, even awk scripts scripts to
generate systemtap code for particular special purposes. So one can
hide the script language as an implementation detail of a higher level
tool. It's not a substitute though.
- FChE
next prev parent reply other threads:[~2008-10-24 19:30 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-11 20:22 [PATCH 5/5] tracing/ftrace: Introduce the big kernel lock tracer Frederic Weisbecker
2008-10-21 12:28 ` Frédéric Weisbecker
2008-10-21 12:33 ` Ingo Molnar
2008-10-21 12:42 ` Frédéric Weisbecker
2008-10-23 18:15 ` Frank Ch. Eigler
2008-10-24 13:43 ` Frédéric Weisbecker
2008-10-24 14:37 ` Frank Ch. Eigler
2008-10-24 14:47 ` Steven Rostedt
2008-10-24 15:02 ` Frank Ch. Eigler
2008-10-24 15:26 ` Frédéric Weisbecker
2008-10-24 19:29 ` Frank Ch. Eigler [this message]
2008-10-29 5:46 ` Tom Zanussi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20081024192949.GC8210@redhat.com \
--to=fche@redhat.com \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rostedt@goodmis.org \
--cc=systemtap@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).