Jim Keniston wrote:
On Wed, 2007-04-11 at 15:21 -0400, Mathieu Desnoyers wrote:
* Andrew Morton ([EMAIL PROTECTED]) wrote:
On Wed, 11 Apr 2007 13:51:11 -0400
Mathieu Desnoyers <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
