This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: [PATCH 5/5] tracing/ftrace: Introduce the big kernel lock tracer
- From: "Frédéric Weisbecker" <fweisbec at gmail dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: "Steven Rostedt" <rostedt at goodmis dot org>, "Ingo Molnar" <mingo at elte dot hu>, linux-kernel at vger dot kernel dot org, systemtap at sources dot redhat dot com
- Date: Fri, 24 Oct 2008 17:26:53 +0200
- Subject: Re: [PATCH 5/5] tracing/ftrace: Introduce the big kernel lock tracer
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=twTbet2CPP2y4Ui8Hj6FolbL91P4TN0SiaebE4aFC88=; b=xU/nGlvsD9kqOogE2L0BdskxPGJ29Q9/5/xJ69r64qtylGpI5R23bNvKPPfEG7ZwqM G9sNdZ5WL+gL8NxDmF27O6JOlihBcHQAqW+bg3wDeCUQjSpID80loFx4/Qd+t5urHKjF dbHmb1dZoALUkA+yJzI6LmtlGgBnIy2b3xlKc=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ixLgmfK4a3RXzIB0TicIfsk5BfB5IuDBuBRzuedv2o4biuNkBBL1oh8aiREoBaHnHw QizhIG7dLGEFaOBbu/M1H4tJVdgAn1Szupcr/DKrm0JFQ0OelNHRvmrWFd3QbqXf1dfA gYnt+d/+o0AHCUoGBPi7ooUy5UrKFwe1uF2XA=
- References: <48F10B0B.406@gmail.com> <c62985530810210528t416c82b2lbe8471322e8359c@mail.gmail.com> <y0mmygv18le.fsf@ton.toronto.redhat.com> <c62985530810240643q467a9060kaf906eb7865f0a7@mail.gmail.com> <20081024143744.GA20768@redhat.com> <alpine.DEB.1.10.0810241046300.3882@gandalf.stny.rr.com> <20081024150239.GB20768@redhat.com>
2008/10/24 Frank Ch. Eigler <fche@redhat.com>:
> That's what we do with the systemtap script, where kernel "handling"
> consists of "running the machine code".
>
>> But have the user application interface be very simple, and perhaps
>> even use perl or python.
>
> perl and python are pretty big procedural languages, and are not
> easily compiled down to compact & quickly executed machine code. (I
> take it no one is suggesting including a perl or python VM in the
> kernel.) Plus, debugger-flavoured event-handling programming style
> would not look nearly as compact in perl/python as in systemtap, which
> is small and domain-specific.
>
> - FChE
>
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.
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, and you just have to capture
commands and works
sent through Api. Then, when the kernel has something to give, you
just have to place it in the
appripriate object and transmit it to the script which is waiting.
Processing and output with the data are done by the python script.
So actually, the python script only needs to ask you what data to
capture. It's its own responsability to
do wathever it wants with.
What do you think?