This is the mail archive of the mailing list for the systemtap project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Vara Prasad/Portland/IBM

08/28/2006 09:19 AM

Trond Myklebust <>

cc, Li Guanglei <>,, "" <>, Tony Reix <>,


Re: Systemtap for NFSv4Vara Prasad <Notes:///87256A9900418B2C/DABA975B9FB113EB852564B5001283EA/3629F4C3A51CA43F872571D600113320>

Trond Myklebust <> wrote on 08/25/2006 08:07:34 PM:

> 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?
> Cheers,
>   Trond

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.

Vara Prasad

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]