Re: [2/3 PATCH] Kprobes: User space probes support- readpage hooks

[Richard J Moore]

Andrew, the need is probably better stated as one where system-wide probing
or tracing is possible. There are times where one needs a global view. Of
course one can use multiple tools to obtain such data e.g. probes in kernel
space strace in user space and so on.  The advantages of supporting user
probes are as follows:

1) A single tool providing the data capture in a consistent manner eases
the problems of correlation of events across multiple tools (for kernel and
user space)
2) The dynamic aspect allows ad hoc probepoints to be inserted  where no
existing instrumentation is provided (emergency debug scenario for
example).
3) The user probe distinguishes itself from all other externally managed
tracing mechanisms in that probepoints are globally applied - i.e. without
reference to PID. Compare this with ptrace breakpoints (hence strace and
gdb) where tracepoints and breakpoints are localized to a specified set of
processes. user-probes achieves this by design without the side effects
(privatization of pages) that ptrace has.  Again this supports the global
view.
4) user-probes also supports the registering of the probepoints before an
the probed code is loaded. The clearly has advantages for catching
initialization problems.


A real life example of where this capability would have been very useful is
with a performance problem I am currently investigating. It involves a GPFS
+ SAMBA + TCPIP +  RDAC and some user-space video serving application. We
are looking are where the latencies are accumulating in the system for the
specific user application. It's a very hard problem. Having multiple tools
serve up a partial view and having to coordinate these view from both data
analysis and data gathering perspectives is a real nightmare.

- -
Richard J Moore
IBM Advanced Linux Response Team - Linux Technology Centre
MOBEX: 264807; Mobile (+44) (0)7739-875237
Office: (+44) (0)1962-817072


                                                                           
             Andrew Morton                                                 
             <akpm@xxxxxxxx>                                               
                                                                        To 
             21/03/2006               prasanna@xxxxxxxxxx                  
             02:12                                                      cc 
                                      ak@xxxxxxx, davem@xxxxxxxxxxxxx,     
                                      suparna@xxxxxxxxxx, Richard J        
                                      Moore/UK/IBM@IBMGB,                  
                                      linux-kernel@xxxxxxxxxxxxxxx         
                                                                       bcc 
                                                                           
                                                                   Subject 
                                      Re: [2/3 PATCH] Kprobes: User space  
                                      probes support- readpage hooks       
                                                                           
                                                                           




Prasanna S Panchamukhi <prasanna@xxxxxxxxxx> wrote:
>
> The basic idea is to insert probes on user applications which may or
>  may not be in memory, at the time of probe insertion.

umm yes, but what for?

What does this entire feature *do*?  Why does Linux need it?

OK, so it allows kernel modules to set breakpoints (via debug traps) into
user code.  But why do we want to be able to do that?  What are the
use-cases?

This may sound like boringly obvious stuff to you, but without a complete
problem statement from the designers, how are we to evaluate their proposed
solution?



-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/