LWN: Comments on "Kernel markers"

Kernel markers

fuhchee — Tue, 02 Oct 2007 19:35:07 +0000

> If and when this code is merged, the way will be clear for the creation of a
> set of well-defined trace points for utilities like SystemTap and LTTng.

Indeed. It may be interesting to point out the systemtap script interface
to the markers - for those who don't want to write their instrumentation
in C. This one just traces the first argument. (It's already working,
which makes sense since we prototyped markers with/before Mathieu.)

probe kernel.mark("name") { println ($arg1) }

We look forward to the inclusion of markers in linux, and their gradual
utilization throughout the code base.

Kernel markers

davecb — Thu, 16 Aug 2007 16:22:42 +0000

It's interesting to compare these with the mostly-dynamic but
sometimes-static approach used in dtrace: almost any function
can be traced without great effort, but a few built-in
static trace points provide higher-level semantics.

A decent explanation of that was Brian Cantrill's comment
at http://lwn.net/Articles/244646/

I speculate that developers of particular kernel areas
would be active in creating and maintaining high-level and
correlated trace information, and end users could take
advantage of them, but being able to trace on, for example,
entry to an arbitrary function would be th next-most-used
functionality.

--dave

Kernel markers

compudj — Thu, 16 Aug 2007 15:58:24 +0000

Hi,

Being the developer behind the Linux Kernel Markers, I would like to add some clarifications:

The argument "For example, the rate of change of the kernel code base would make the maintenance of a large set of probe points difficult, especially given that developers working on many parts of the code might not be particularly aware of - or concerned about - those points." should be put in context. Actually, if we think of tracing as being provided not only to Linux users, but also to kernel developers, embedded developers, etc, it makes sense to have an intrumentation set which follows the kernel source as closely as possible.

SystemTap's approach of creating an external tapset that have to be ported to each new kernel is correct for users of distribution kernels, but requires much more effort when trying to adapt the tapsets to a rapidly changing code base.

One of the advantages of putting markers at important locations in the kernel code is that they follow the code flow and use the underlying revision control system of the kernel. Moreover, the developers who are the most likely to know what trace points must be inserted and where are probably the maintainers of a subsystem themself. Therefore, it makes sense for them to be the final deciders on wether or not a trace point belongs to a kernel code path.

Second point, the immediate values optimized versions are currently implemented for i386 and powerpc.

Thanks for this thorough coverage of the state of the markers/immediate values.

Mathieu