RE: Co-oridnate system for adding probes

["Chen, Brad" <brad dot chen at intel dot com>]

Thanks for getting this started.

Question: is this supposed to be the list of probe
point types for our performance analysis users, or 
is it supposed to include the broader set of 
capabilities that kernel debugging people want?

Clearly performance analysts have very different
needs from people debugging the kernel, and I'm
wondering about how this is going to reflect itself
in the design of the system.

ALSO I wanted to suggest a refinement to the "Event 
Based" notes:

> 1) When a particular event like timer or page fault  etc. occurs.
I think we want to be explicit that we are talking about
hardware events, right? My assumption is that software
events would be captured through the first set of probe
types. If you wanted to include software events, then
perhaps you can add it to the list and give some examples.

> 2) A particular memory location is accessed using watch point
mechanism.
> This mechanism is limited to number of debug registers but extensible
using
> software although performance of such an extension needs to be
studied.
> 3 )Exceeding a set resource limit. For example asking for memory more
than
> a given size, high water marks as Brad mentioned etc.
At some point we'll have to go through a refinement step
to figure out which of these need to be implemented
directly and which can be layered on top of some basic
probe types.

Brad

-----Original Message-----
From: systemtap-owner@sources.redhat.com
[mailto:systemtap-owner@sources.redhat.com] On Behalf Of Vara Prasad
Sent: Wednesday, March 09, 2005 5:47 PM
To: systemtap@sources.redhat.com
Subject: Co-oridnate system for adding probes

Hi,

    Here is the initial list of coordinates that we can use to define 
probe points

Code or Program counter based
1) Entry: We already have code for this and the need is obvious.
2) Exit: Prototype code is out and the need is obvious.
3) At the label: Kernel has goto labels in many functions to jump out
    for error handling and other needs. This probe instruction will be 
the first instruction
    to get executed once the label is reached.
4) Insert a probe at a line number in the file or function + offset. As 
you can see both
    of these are not very portable from one version to other and 
platform to platform.
5) Insert a probe before calling a specified function. If there are 
multiple calls to the
    specified function default is to put the probe before the first 
call.  I would like to clarify
    this a bit. For example in the following code
     line#   
     99       a=bar(x,y)
    100      if  (foo (a, max (b,c), min (c,d))
     101         z=10;  
    
    if probe specifies that we should add a probe before calling 
function min().
    It means we need to add the probe before executing line 100
entirely.
    In other words this is a more reliable and portable way of 
specifying  a line
    of code where we should put a probe then the line number.
6) After returning from a specified function call. This is potentially 
not a
    good one to implement because of branching after the call. In other 
words
    if we have code like the following
    if  (foo())
       .....
    else
       ....
    we have to add probe in both parts of the if, which we may or may 
not be able
     to do it correctly due to compiler optimizations.
7)  At the beginning of a function only if that function is called from 
a specified function.
     In this case we could make generic kprobe handler to check for the 
calling function
     address and call the registered probe only if the calling function 
matches to the
     specified one otherwise continue as if nothing happened. This still

has the performance
     penalty of hitting a trap if the calee is not the required one.

Event  based

1) When a particular event like timer or page fault  etc. occurs.
2) A particular memory location is accessed using watch point mechanism.
This mechanism is limited to number of debug registers but extensible
using
software although performance of such an extension needs to be studied.
3 )Exceeding a set resource limit. For example asking for memory more
than
a given size, high water marks as Brad mentioned etc.

Static Trace points
If we can do most of the above then we will be able to get a much better

view
of the system then we can today, however we may not be able to reach all
the places of the code that we need. We might be able to convince kernel
community for a limited set of static trace points after we show the
value
of the tool using the above dynamic methods. I have also seen some
evidence
from the community to accept limited NO OP markers in the mailing list,
but
i think we have to first show our value using dynamic methods.

1) A simple NO OP marker with a good comment so people don't remove it.
2)  Real trace function call in the code itself. This is bit more 
controversial
with the community, we should consider this as the last resort.

This is just a start before i get way behind. I am sure there are other 
methods i have not
covered. After we agree upon which of the co-ordinate systems make sense

then
we can work on ways to specify them in the language.

bye,
Vara Prasad