Re: [PATCH] markers-linker-generic

[Vara Prasad <prasadav@us.ibm.com>]

Jim Keniston wrote:

> On Wed, 2007-04-11 at 15:21 -0400, Mathieu Desnoyers wrote:
>  
>
> > * Andrew Morton (akpm@linux-foundation.org) wrote:
> >    
> >
> > > On Wed, 11 Apr 2007 13:51:11 -0400
> > > Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> wrote:
> > >
> > >      
> > >
> > > > > What's this marker stuff about?
> > > > >
> > > > >          
> > > > Hi Russel,
> > > >
> > > > Here is an overview :
> > > >        
> > > I am told that the systemtap developers plan to (or are) using this
> > > infrastructure.
> > >
> > >      
> > Quoting Frank Ch. Eigler, from the SystemTAP team :
> >
> > "The LTTng user-space programs use it today.  Systemtap used to support
> > the earlier marker prototype and will be rapidly ported over to this
> > new API upon acceptance."
> >
> >
> >    
> >
> > > If correct: what is their reason for preferring it over kprobes?
> > >      
Markers are not a substitute or preference over kprobes, they augment 
kprobes by enabling additional functionality.

> > >      
> > I will let them answer on this one..
> >
> >    
>
> I'll take a shot at this one.
>
> First of all, kprobes remains a vital foundation for SystemTap.  But
> markers are attactive as an alternate source of trace/debug info.
> Here's why:
>
> 1. Markers will live in the kernel and presumably be kept up to date by
> the maintainers of the enclosing code.  We have a growing set of tapsets
> (probe libraries), each of which "knows" the source code for a certain
> area of the kernel.  Whenever the underlying kernel code changes (e.g.,
> a function or one of its args disappears or is renamed), there's a
> chance that the tapset will become invalid until we bring it back in
> sync with the kernel.  As you can imagine, maintaining tapsets separate
> from the kernel source is a maintenance headache.  Markers could
> mitigate this.
>  
Jim's above stated reason is not a consideration for markers. We don't 
plan to convert the current tapsets to use markers. We do need to 
augment tapsets with a few markers in the kernel code where it is not 
easy to put a kprobe in a maintainable fashion -- e.g in the middle of a 
function.

> 2. Because the kernel code is highly optimized, the kernel's dwarf info
> doesn't always accurately reflect which variables have which values on
> which lines (sometimes even upon entry to a function).  A marker is a
> way to ensure that values of interest are available to SystemTap at
> marked points.
>  
Agreed

> 3. Sometimes the overhead of a kprobe probepoint is too much (either in
> terms of time or locking) for the particular hotspot we want to probe.
>
>  
Agreed

> Jim
>
>  
bye,
Vara Prasad

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