[Fwd: Fw: Systemtap for NFSv4]

[Vara Prasad <prasadav at us dot ibm dot com>]

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

	

To
	
Trond Myklebust <trond.myklebust@fys.uio.no>

cc
	
gh@us.ltcfwd.linux.ibm.com, Li Guanglei <guanglei@cn.ibm.com>, 
jrs@us.ltcfwd.linux.ibm.com, "systemtap@sourceware.org" 
<systemtap@sourceware.org>, Tony Reix <tony.reix@bull.net>, 
xuepengl@cn.ibm.com

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


	


Trond Myklebust <trond.myklebust@fys.uio.no> 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.

bye,
Vara Prasad