Re: [PATCH] markers-linker-generic

Vara Prasad
2007-04-12T00:22:10Z

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