Root/
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, "myint %d mystring %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 | - "myint %d mystring %s" is the formatted string for the serializer. "myint" and |
44 | "mystring" are repectively the field names associated with the first and |
45 | second parameter. |
46 | - someint is an integer. |
47 | - somestring is a char pointer. |
48 | |
49 | Connecting a function (probe) to a marker is done by providing a probe (function |
50 | to call) for the specific marker through marker_probe_register() and can be |
51 | activated by calling marker_arm(). Marker deactivation can be done by calling |
52 | marker_disarm() as many times as marker_arm() has been called. Removing a probe |
53 | is done through marker_probe_unregister(); it will disarm the probe. |
54 | |
55 | marker_synchronize_unregister() must be called between probe unregistration and |
56 | the first occurrence of |
57 | - the end of module exit function, |
58 | to make sure there is no caller left using the probe; |
59 | - the free of any resource used by the probes, |
60 | to make sure the probes wont be accessing invalid data. |
61 | This, and the fact that preemption is disabled around the probe call, make sure |
62 | that probe removal and module unload are safe. See the "Probe example" section |
63 | below for a sample probe module. |
64 | |
65 | The marker mechanism supports inserting multiple instances of the same marker. |
66 | Markers can be put in inline functions, inlined static functions, and |
67 | unrolled loops as well as regular functions. |
68 | |
69 | The naming scheme "subsystem_event" is suggested here as a convention intended |
70 | to limit collisions. Marker names are global to the kernel: they are considered |
71 | as being the same whether they are in the core kernel image or in modules. |
72 | Conflicting format strings for markers with the same name will cause the markers |
73 | to be detected to have a different format string not to be armed and will output |
74 | a printk warning which identifies the inconsistency: |
75 | |
76 | "Format mismatch for probe probe_name (format), marker (format)" |
77 | |
78 | Another way to use markers is to simply define the marker without generating any |
79 | function call to actually call into the marker. This is useful in combination |
80 | with tracepoint probes in a scheme like this : |
81 | |
82 | void probe_tracepoint_name(unsigned int arg1, struct task_struct *tsk); |
83 | |
84 | DEFINE_MARKER_TP(marker_eventname, tracepoint_name, probe_tracepoint_name, |
85 | "arg1 %u pid %d"); |
86 | |
87 | notrace void probe_tracepoint_name(unsigned int arg1, struct task_struct *tsk) |
88 | { |
89 | struct marker *marker = &GET_MARKER(kernel_irq_entry); |
90 | /* write data to trace buffers ... */ |
91 | } |
92 | |
93 | * Probe / marker example |
94 | |
95 | See the example provided in samples/markers/src |
96 | |
97 | Compile them with your kernel. |
98 | |
99 | Run, as root : |
100 | modprobe marker-example (insmod order is not important) |
101 | modprobe probe-example |
102 | cat /proc/marker-example (returns an expected error) |
103 | rmmod marker-example probe-example |
104 | dmesg |
105 |
Branches:
ben-wpan
ben-wpan-stefan
javiroman/ks7010
jz-2.6.34
jz-2.6.34-rc5
jz-2.6.34-rc6
jz-2.6.34-rc7
jz-2.6.35
jz-2.6.36
jz-2.6.37
jz-2.6.38
jz-2.6.39
jz-3.0
jz-3.1
jz-3.11
jz-3.12
jz-3.13
jz-3.15
jz-3.16
jz-3.18-dt
jz-3.2
jz-3.3
jz-3.4
jz-3.5
jz-3.6
jz-3.6-rc2-pwm
jz-3.9
jz-3.9-clk
jz-3.9-rc8
jz47xx
jz47xx-2.6.38
master
Tags:
od-2011-09-04
od-2011-09-18
v2.6.34-rc5
v2.6.34-rc6
v2.6.34-rc7
v3.9