This is the mail archive of the
systemtap@sourceware.org
mailing list for the systemtap project.
Re: A blktrace tapset, or 101 things you can do with blktrace and systemtap
- From: Tom Zanussi <zanussi at comcast dot net>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: systemtap at sourceware dot org, linux-btrace at vger dot kernel dot org
- Date: Mon, 05 Mar 2007 11:33:51 -0600
- Subject: Re: A blktrace tapset, or 101 things you can do with blktrace and systemtap
- References: <1173067754.4683.48.camel@ubuntu> <y0mirdfina8.fsf@ton.toronto.redhat.com>
On Mon, 2007-03-05 at 12:59 -0500, Frank Ch. Eigler wrote:
> Tom Zanussi <zanussi@comcast.net> writes:
> > # stap -I tapsets countall.stp
> > # btrace /dev/hda
>
> Is there some way for the systemtap script to perform the tracing
> activation done by the btrace tool?
AFAIK, there's no API in blktrace that would allow the runtime to easily
toggle tracing on/off from the kernel side. It would probably take just
a couple lines of code to add something that would do it, but that would
also add a couple to tests to the logging path, which I doubt would be
acceptable. So probably best to just have a shell script that starts
the systemtap script and also starts blktrace. Personally I don't find
it too onerous to start blktrace manually, but I'm guessing you might
have other possibilities in mind for solving this problem. ;-)
>
> > [...] This script needs a couple extra changes to the normal commandline, so
> > it doesn't choke on some default systemtap limits:
> > # stap -I tapsets -DMAXMAPENTRIES=10000 -DMAXACTION=10000 iotop.stp
> > [...]
>
> In what cases would your script come up against the MAXACTION limits?
I probably just kept this command-line from previous tests where it did
matter - I often use these defensively in order to avoid having a
long-running script run to completion only to choke at the end when
printing the results.
Tom