Differences between revisions 6 and 7
Revision 6 as of 2008-01-11 17:09:07
Size: 2298
Editor: DavidSmith
Comment:
Revision 7 as of 2008-01-11 17:19:02
Size: 2528
Editor: DavidSmith
Comment:
Deletions are marked like this. Additions are marked like this.
Line 12: Line 12:
Line 27: Line 26:
Line 31: Line 29:
The marker subsystem and the kernel markers themselves must be compiled into your kernel. Initial marker support is present in 2.6.24, but at this time you must also add 3 patches from the mm tree to get full marker functionality.
Line 32: Line 31:
The marker subsystem and the kernel markers themselves must be compiled into your kernel. Initial marker support is present in 2.6.24, but at this time you must also add 2 patches from the mm tree to get full marker functionality. The first patch adds support for multiple probes per markers.
The second patch adds support for creating a file called Module.markers which lists all markers present in a kernel and its modules (similar to the Module.symvers file).

Using Markers

What are markers?

Here is some text taken from the kernel documentation that describes markers:

  • A marker placed in code provides a hook to call a function (probe) that you can provide at runtime. A marker can be "on" (a probe is connected to it) or "off" (no probe is attached). When a marker is "off" it has no effect, except for adding a tiny time penalty (checking a condition for a branch) and space penalty (adding a few bytes for the function call at the end of the instrumented function and adds a data structure in a separate section). When a marker is "on", the function you provide is called each time the marker is executed, in the execution context of the caller. When the function provided ends its execution, it returns to the caller (continuing from the marker site).
  • You can put markers at important locations in the code. Markers are lightweight hooks that can pass an arbitrary number of parameters, described in a printk-like format string, to the attached probe function.
  • They can be used for tracing and performance accounting.

What do markers in kernel code look like?

#include <linux/marker.h>
//...
int kfunc(int mask)
{
        int rc = 0;        // return code
        trace_mark(kfunc_entry, "mask %d", mask);

        //... bulk of kfunc() here...

        trace_mark(kfunc_exit, "rc %d", rc);
        return(rc);
}

This function (named 'kfunc'), has 2 markers present in it. The first one has a subsystem_event of "kfunc_entry" and the second marker has a subsystem_event of "kfunc_exit". The kernel documentation suggests treating the first argument of trace_mark as having 2 parts: a 'subsystem' and an 'event'. In our example, the name of the function is used as the subsystem, and 'entry' and 'exit' are used as the events. As you can see, the second argument to trace_mark() is a format string (similar to one used by printk()), and the rest of the arguments depend on the format string.

How do I turn on marker support in my kernel?

The marker subsystem and the kernel markers themselves must be compiled into your kernel. Initial marker support is present in 2.6.24, but at this time you must also add 3 patches from the mm tree to get full marker functionality.

The first patch adds support for multiple probes per markers. The second patch adds support for creating a file called Module.markers which lists all markers present in a kernel and its modules (similar to the Module.symvers file).

None: UsingMarkers (last edited 2009-02-21 01:51:00 by JoshStone)