This is the mail archive of the
mailing list for the systemtap project.
[Fwd: Fw: Systemtap for NFSv4]
- From: Vara Prasad <prasadav at us dot ibm dot com>
- To: systemtap <systemtap at sourceware dot org>
- Date: Mon, 28 Aug 2006 09:41:49 -0700
- Subject: [Fwd: Fw: Systemtap for NFSv4]
My following reply to Trond's posting didn't show up in the mailing list
due to my mailer issue, i am resending it to the mailing list again.
08/28/2006 09:19 AM
Trond Myklebust <firstname.lastname@example.org>
email@example.com, Li Guanglei <firstname.lastname@example.org>,
<email@example.com>, Tony Reix <firstname.lastname@example.org>,
Re: Systemtap for NFSv4Vara Prasad
Trond Myklebust <email@example.com> wrote on 08/25/2006
> On Wed, 2006-08-23 at 09:41 -0700, Gerrit Huizenga wrote:
> > > Note: if we do want to replace dprintks with SystemTap, then I think
> > > that another precondition would be that we include the main systemtap
> > > debugging scripts in Linus' tree.
> > That has also been discussed - and I think that is a valid proposal.
> > Not sure what the current status is but if the SystemTap folks agree,
> > that is an easy discussion to start on LKML or with akpm.
> Hmm.... I see that the netdev folks have started an alternative to
> systemtap when it comes to in-kernel debugging. I assume you have seen
> the file net/ipv4/tcp_probe.c?
> They use jprobes to just patch in a 'debugging module' that contains the
> printk()s that might be of interest. How about this as an alternative?
This is a good start but there are few issues with this proposal.
1) Jprobes only works at the beginning of the function, we still need to
come up with a proper maker mechanism acceptable to everyone for placing
probes in the middle of the function.
2) The output goes to syslog and is mingled with all the other messages
hence not easy to parse out.
3) All the probe points will be active once the module is loaded, no
selectivity of which probes to activate, imagine the performance penalty
if we load all the modules that instrument the entire subsystems.
4) One can not filter and aggregate the probe data based on some
complicated parameters in the kernel, (in the case of tcpprobe there is
only one simple port parameter) it needs to be done in user space which
means we will be sending whole lot of data from the kernel using
precious cycles even when we don't need it.
This is what i can think of as major issues others may have some other.