Cc: Linus Torvalds <torvalds@...>, Jeff Garzik <jeff@...>, Randy Dunlap <rdunlap@...>, <hch@...>, <linux-kernel@...>, Sam Ravnborg <sam@...>, Jens Axboe <jens.axboe@...>, Prasanna S Panchamukhi <prasanna@...>, Ananth N Mavinakayanahalli <ananth@...>, Anil S Keshavamurthy <anil.s.keshavamurthy@...>, David S. Miller <davem@...>, Ingo Molnar <mingo@...>, Peter Zijlstra <pzijlstr@...>, Philippe Elie <phil.el@...>, William L. Irwin <wli@...>, Arjan van de Ven <arjan@...>, Christoph Lameter <christoph@...>, <Valdis.Kletnieks@...>
That's right, Systemtap uses symbols, thanks for the clarification. But
my point is still valid: SystemTAP expects function names and argument
names to stay unchanged, therefore using the kernel code itself as an
API to userspace tools. The markers act as a buffer between what
important events userspace tools expect and the actual kernel code.
I have not been able to detect a significant dormant marker overhead
with the immediate values optimization. A load immediate and a predicted
conditional jump are surprisingly cheap.
Yes. I expect that kind of mark-up to be kept minimalistic.
I think that SystemTAP's flexibility is great, but leads to fagileness
wrt kernel code changes. If the "core events" required by SystemTAP
(and also by LTTng by the way) could be turned into markers, I think it
would gain in robustness.
Providing the ability to instrument code locations with breakpoints, in
addition to this, will help users unsatisfied with the information
they have, unwilling to recompile their kernel or modules with their
own markers, ready to accept the two limitations :
- performance hit of a breakpoint
- unability to access variables within optimized functions
So yes, both approaches seems to be complementary.
Yes, I think he did a good job at it. However, it is not a replacement
for the markers, SystemTAP or LTTng, because it defines a limited
set of hardcoded events (implying yet another type of code markup) that
is by itself a pain to extend. I am not willing to ask a subsystem
maintainer to do more than to "just identify" their important code
paths, the equivalent of adding a printk to their code. I don't think it
is realistic to ask them to create specialized callbacks for each of the
sites they would like to instrument.
So I would say : I'll try to submit a core set of markers patches for
review on LKML and see what people have to say.
Mathieu
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
-
