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