Mathieu Desnoyers | 26e3d11 | 2007-10-18 23:41:08 -0700 | [diff] [blame] | 1 | Using the Linux Kernel Markers |
| 2 | |
| 3 | Mathieu Desnoyers |
| 4 | |
| 5 | |
| 6 | This document introduces Linux Kernel Markers and their use. It provides |
| 7 | examples of how to insert markers in the kernel and connect probe functions to |
| 8 | them and provides some examples of probe functions. |
| 9 | |
| 10 | |
| 11 | * Purpose of markers |
| 12 | |
| 13 | A marker placed in code provides a hook to call a function (probe) that you can |
| 14 | provide at runtime. A marker can be "on" (a probe is connected to it) or "off" |
| 15 | (no probe is attached). When a marker is "off" it has no effect, except for |
| 16 | adding a tiny time penalty (checking a condition for a branch) and space |
| 17 | penalty (adding a few bytes for the function call at the end of the |
| 18 | instrumented function and adds a data structure in a separate section). When a |
| 19 | marker is "on", the function you provide is called each time the marker is |
| 20 | executed, in the execution context of the caller. When the function provided |
| 21 | ends its execution, it returns to the caller (continuing from the marker site). |
| 22 | |
| 23 | You can put markers at important locations in the code. Markers are |
| 24 | lightweight hooks that can pass an arbitrary number of parameters, |
| 25 | described in a printk-like format string, to the attached probe function. |
| 26 | |
| 27 | They can be used for tracing and performance accounting. |
| 28 | |
| 29 | |
| 30 | * Usage |
| 31 | |
| 32 | In order to use the macro trace_mark, you should include linux/marker.h. |
| 33 | |
| 34 | #include <linux/marker.h> |
| 35 | |
| 36 | And, |
| 37 | |
| 38 | trace_mark(subsystem_event, "%d %s", someint, somestring); |
| 39 | Where : |
| 40 | - subsystem_event is an identifier unique to your event |
| 41 | - subsystem is the name of your subsystem. |
| 42 | - event is the name of the event to mark. |
| 43 | - "%d %s" is the formatted string for the serializer. |
| 44 | - someint is an integer. |
| 45 | - somestring is a char pointer. |
| 46 | |
| 47 | Connecting a function (probe) to a marker is done by providing a probe (function |
| 48 | to call) for the specific marker through marker_probe_register() and can be |
| 49 | activated by calling marker_arm(). Marker deactivation can be done by calling |
| 50 | marker_disarm() as many times as marker_arm() has been called. Removing a probe |
| 51 | is done through marker_probe_unregister(); it will disarm the probe and make |
| 52 | sure there is no caller left using the probe when it returns. Probe removal is |
| 53 | preempt-safe because preemption is disabled around the probe call. See the |
| 54 | "Probe example" section below for a sample probe module. |
| 55 | |
| 56 | The marker mechanism supports inserting multiple instances of the same marker. |
| 57 | Markers can be put in inline functions, inlined static functions, and |
| 58 | unrolled loops as well as regular functions. |
| 59 | |
| 60 | The naming scheme "subsystem_event" is suggested here as a convention intended |
| 61 | to limit collisions. Marker names are global to the kernel: they are considered |
| 62 | as being the same whether they are in the core kernel image or in modules. |
| 63 | Conflicting format strings for markers with the same name will cause the markers |
| 64 | to be detected to have a different format string not to be armed and will output |
| 65 | a printk warning which identifies the inconsistency: |
| 66 | |
| 67 | "Format mismatch for probe probe_name (format), marker (format)" |
| 68 | |
| 69 | |
| 70 | * Probe / marker example |
| 71 | |
| 72 | See the example provided in samples/markers/src |
| 73 | |
| 74 | Compile them with your kernel. |
| 75 | |
| 76 | Run, as root : |
| 77 | modprobe marker-example (insmod order is not important) |
| 78 | modprobe probe-example |
| 79 | cat /proc/marker-example (returns an expected error) |
| 80 | rmmod marker-example probe-example |
| 81 | dmesg |