Skip to contentSkip to conversation

Linux Kernel Markers

PATCH In review Mathieu Desnoyers 3 participants 11 messages Aug 20, 2007 – Aug 28, 2007

Subsystems (19)
Memory management Documentation Arm (32-bit) VFS +15 more subsystems
lore
Share & tools
lore

Mathieu Desnoyers

author
#0 lore raw

cover Linux Kernel Markers

Hi Andrew,

Here is the new version of the kernel markers. Changes since last post:

- Documentation fixes.

Applies to 2.6.23-rc2-mm2, in this order:

linux-kernel-markers-architecture-independent-code.patch linux-kernel-markers-kconfig-menus.patch linux-kernel-markers-documentation.patch linux-kernel-markers-port-blktrace-to-markers.patch

Mathieu

Signature · 3 lines
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
author
#1 lore raw

PATCH 1/4 Linux Kernel Markers - Architecture Independent Code

The marker activation functions sits in kernel/marker.c. A hash table is used to keep track of the registered probes and armed markers, so the markers within a newly loaded module that should be active can be activated at module load time.

marker_query has been removed. marker_get_first, marker_get_next and marker_release should be used as iterators on the markers.

Signed-off-by Mathieu Desnoyers <[email protected]>

---

 include/asm-generic/vmlinux.lds.h |   11 
 include/linux/marker.h            |  170 +++++++++
 include/linux/module.h            |    5 
 kernel/marker.c                   |  678 ++++++++++++++++++++++++++++++++++++++
 kernel/module.c                   |   19 +
 5 files changed, 882 insertions(+), 1 deletion(-)
include/asm-generic/vmlinux.lds.h +10 -1
Index: linux-2.6-lttng/include/asm-generic/vmlinux.lds.h
===================================================================
@@ -12,7 +12,11 @@
 /* .data section */
 #define DATA_DATA							\
 	*(.data)							\
-	*(.data.init.refok)
+	*(.data.init.refok)						\
+	. = ALIGN(8);							\
+	VMLINUX_SYMBOL(__start___markers) = .;				\
+	*(__markers)							\
+	VMLINUX_SYMBOL(__stop___markers) = .;
 
 #define RO_DATA(align)							\
 	. = ALIGN((align));						\

@@ -129,6 +133,11 @@
 		VMLINUX_SYMBOL(__stop___immediate) = .;			\
 	}								\
 									\
+	/* Markers: strings */						\
+        __markers_strings : AT(ADDR(__markers_strings) - LOAD_OFFSET) {	\
+		*(__markers_strings)					\
+ 	}								\
+									\
 	/* Kernel symbol table: strings */				\
         __ksymtab_strings : AT(ADDR(__ksymtab_strings) - LOAD_OFFSET) {	\
 		*(__ksymtab_strings)					\
include/linux/marker.h new file +170 -0

170 lines not on this page · raw message

include/linux/module.h +5 -0
Index: linux-2.6-lttng/include/linux/module.h
===================================================================
@@ -16,6 +16,7 @@
 #include <linux/kobject.h>
 #include <linux/moduleparam.h>
 #include <linux/immediate.h>
+#include <linux/marker.h>
 #include <asm/local.h>
 
 #include <asm/module.h>

@@ -380,6 +381,10 @@ struct module
 	const struct __immediate *immediate;
 	unsigned int num_immediate;
 #endif
+#ifdef CONFIG_MARKERS
+	struct __mark_marker *markers;
+	unsigned int num_markers;
+#endif
 };
 #ifndef MODULE_ARCH_INIT
 #define MODULE_ARCH_INIT {}
kernel/module.c +19 -0
Index: linux-2.6-lttng/kernel/module.c
===================================================================
@@ -1722,6 +1722,8 @@ static struct module *load_module(void _
 	unsigned int unusedgplindex;
 	unsigned int unusedgplcrcindex;
 	unsigned int immediateindex = 0;
+	unsigned int markersindex = 0;
+	unsigned int markersstringsindex = 0;
 	struct module *mod;
 	long err = 0;
 	void *percpu = NULL, *ptr = NULL; /* Stops spurious gcc warning */

@@ -1821,6 +1823,10 @@ static struct module *load_module(void _
 #ifdef CONFIG_IMMEDIATE
 	immediateindex = find_sec(hdr, sechdrs, secstrings, "__immediate");
 #endif
+#ifdef CONFIG_MARKERS
+	markersindex = find_sec(hdr, sechdrs, secstrings, "__markers");
+ 	markersstringsindex = find_sec(hdr, sechdrs, secstrings, "__markers_strings");
+#endif
 
 	/* Don't keep modinfo section */
 	sechdrs[infoindex].sh_flags &= ~(unsigned long)SHF_ALLOC;

@@ -1980,6 +1986,10 @@ static struct module *load_module(void _
 			sechdrs[immediateindex].sh_size / sizeof(*mod->immediate);
 	}
 #endif
+	if (markersindex)
+		sechdrs[markersindex].sh_flags |= SHF_ALLOC;
+	if (markersstringsindex)
+		sechdrs[markersstringsindex].sh_flags |= SHF_ALLOC;
 
 	mod->unused_syms = (void *)sechdrs[unusedindex].sh_addr;
 	if (unusedcrcindex)

@@ -2021,6 +2031,13 @@ static struct module *load_module(void _
 		if (err < 0)
 			goto cleanup;
 	}
+#ifdef CONFIG_MARKERS
+	if (markersindex) {
+		mod->markers = (void *)sechdrs[markersindex].sh_addr;
+		mod->num_markers =
+			sechdrs[markersindex].sh_size / sizeof(*mod->markers);
+	}
+#endif
 
         /* Find duplicate symbols */
 	err = verify_export_symbols(mod);

@@ -2046,6 +2063,8 @@ static struct module *load_module(void _
 	 }
 #endif
 
+	module_marker_update(mod);
+
 	module_immediate_setup(mod);
 
 	err = module_finalize(hdr, sechdrs, mod);
kernel/marker.c new file +678 -0

678 lines not on this page · raw message

Signature · 3 lines
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
#2 lore raw

Re: [patch 1/4] Linux Kernel Markers - Architecture Independent Code

Quoted 4 lines · Mathieu Desnoyers

The marker activation functions sits in kernel/marker.c. A hash table is used to keep track of the registered probes and armed markers, so the markers within a newly loaded module that should be active can be activated at module load time.

Hi Mathieu!

Just reading through this patch, a couple of comments:

include/linux/marker.h line 136

Quoted 4 lines
include/linux/marker.h new file +4 -0
+/* To be used for string format validity checking with gcc */
+static inline void __mark_check_format(const char *fmt, ...)
+		__attribute__ ((format (printf, 1, 2)));
+static inline void __mark_check_format(const char *fmt, ...) { }

If you place the __attribute__() before the function name, you can do this in the definition.

kernel/module.c static struct module *load_module(void _ · line 1993

Quoted 12 lines

===================================================================

kernel/module.c +4 -0
@@ -1980,6 +1986,10 @@ static struct module *load_module(void _
 			sechdrs[immediateindex].sh_size / sizeof(*mod->immediate);
 	}
 #endif
+	if (markersindex)
+		sechdrs[markersindex].sh_flags |= SHF_ALLOC;
+	if (markersstringsindex)
+		sechdrs[markersstringsindex].sh_flags |= SHF_ALLOC;

Perhaps I'm missing something, but I don't see why these sections wouldn't be SHF_ALLOC already.

kernel/module.c static struct module *load_module(void _ · line 2040

Quoted 13 lines
kernel/module.c +7 -0
 	mod->unused_syms = (void *)sechdrs[unusedindex].sh_addr;
 	if (unusedcrcindex)

@@ -2021,6 +2031,13 @@ static struct module *load_module(void _
 		if (err < 0)
 			goto cleanup;
 	}
+#ifdef CONFIG_MARKERS
+	if (markersindex) {
+		mod->markers = (void *)sechdrs[markersindex].sh_addr;
+		mod->num_markers =
+			sechdrs[markersindex].sh_size / sizeof(*mod->markers);
+	}
+#endif

Because of the wonders of ELF, section 0 has sh_addr and sh_size 0. So the if (markersindex) is unnecessary here.

kernel/module.c static struct module *load_module(void _

Quoted 6 lines
kernel/module.c +6 -0
+/*
+ * Get marker if the marker is present in the marker hash table.
+ * Must be called with markers_mutex held.
+ * Returns NULL if not present.
+ */
+static struct marker_entry *_get_marker(const char *name)

You seem to really enjoy underscores, yet I'm having trouble understanding why this would have an underscore in it.

Quoted 4 lines
kernel/module.c +4 -0
+{
+	struct hlist_head *head;
+	struct hlist_node *node;
+	struct marker_entry *e;

kernel/module.c

Quoted 10 lines
kernel/module.c +10 -0
+	size_t len = strlen(name) + 1;
+	u32 hash = jhash(name, len-1, 0);
+
+	head = &marker_table[hash & ((1 << MARKER_HASH_BITS)-1)];
+	hlist_for_each_entry(e, node, head, hlist) {
+		if (!strcmp(name, e->name))
+			return e;
+	}
+	return NULL;
+}

OK, don't understand the strlen, len, len-1 dance here?

kernel/module.c

Quoted 5 lines
kernel/module.c +5 -0
+/*
+ * Updates the probe callback corresponding to a range of markers.
+ * Must be called with markers_mutex held.
+ */
+static void _marker_update_probe_range(

And yet:

kernel/module.c

Quoted 6 lines
kernel/module.c +6 -0
+void module_marker_update(struct module *mod)
+{
+	if (!mod->taints)
+		_marker_update_probe_range(mod->markers,
+			mod->markers+mod->num_markers, NULL, NULL);
+}

This doesn't hold the markers_mutex.

Cheers,
Rusty.

author
#3 lore raw

Re: [patch 1/4] Linux Kernel Markers - Architecture Independent Code

Quoted 10 lines · * Rusty Russell ([email protected]) wrote:
Quoted 4 lines · Mathieu Desnoyers

The marker activation functions sits in kernel/marker.c. A hash table is used to keep track of the registered probes and armed markers, so the markers within a newly loaded module that should be active can be activated at module load time.

Hi Mathieu!

Just reading through this patch, a couple of comments:

Hi Rusty,

Quoted 8 lines

include/linux/marker.h line 136

Quoted 4 lines
include/linux/marker.h new file +4 -0
+/* To be used for string format validity checking with gcc */
+static inline void __mark_check_format(const char *fmt, ...)
+		__attribute__ ((format (printf, 1, 2)));
+static inline void __mark_check_format(const char *fmt, ...) { }

If you place the __attribute__() before the function name, you can do this in the definition.

Ok, will fix.

Quoted 7 lines
Quoted 7 lines

===================================================================

kernel/module.c +0 -0
@@ -1980,6 +1986,10 @@ static struct module *load_module(void _
 			sechdrs[immediateindex].sh_size / sizeof(*mod->immediate);
 	}
 #endif
Quoted 9 lines

kernel/module.c static struct module *load_module(void _ · line 1993

Quoted 5 lines
kernel/module.c +4 -0
+	if (markersindex)
+		sechdrs[markersindex].sh_flags |= SHF_ALLOC;
+	if (markersstringsindex)
+		sechdrs[markersstringsindex].sh_flags |= SHF_ALLOC;

Perhaps I'm missing something, but I don't see why these sections wouldn't be SHF_ALLOC already.

Declaring variables with __attribute__((section("__markers_strings"))) will likely put them in an allocated section, you are right. Will fix.

The same applies to immediate values with .section __immediate, \"a\", @progbits, which is explicitely allocated.

Quoted 8 lines
Quoted 8 lines
kernel/module.c +2 -0
 	mod->unused_syms = (void *)sechdrs[unusedindex].sh_addr;
 	if (unusedcrcindex)

@@ -2021,6 +2031,13 @@ static struct module *load_module(void _
 		if (err < 0)
 			goto cleanup;
 	}
+#ifdef CONFIG_MARKERS
+	if (markersindex) {
Quoted 9 lines

kernel/module.c static struct module *load_module(void _ · line 2040

Quoted 5 lines
kernel/module.c +5 -0
+		mod->markers = (void *)sechdrs[markersindex].sh_addr;
+		mod->num_markers =
+			sechdrs[markersindex].sh_size / sizeof(*mod->markers);
+	}
+#endif

Because of the wonders of ELF, section 0 has sh_addr and sh_size 0. So the if (markersindex) is unnecessary here.

Ok. Will apply to immediate values too.

Quoted 10 lines

kernel/module.c static struct module *load_module(void _

Quoted 6 lines
kernel/module.c +6 -0
+/*
+ * Get marker if the marker is present in the marker hash table.
+ * Must be called with markers_mutex held.
+ * Returns NULL if not present.
+ */
+static struct marker_entry *_get_marker(const char *name)

You seem to really enjoy underscores, yet I'm having trouble understanding why this would have an underscore in it.

Just they are internal functiona meant to be called with markers_mutex held. But I guess having a static prefix and not being exported is enough. Will remove. I'll just keep _marker_update_probes/marker_update_probes to differentiate between locked/non-locked version.

Quoted 8 lines
Quoted 8 lines
kernel/module.c +8 -0
+{
+	struct hlist_head *head;
+	struct hlist_node *node;
+	struct marker_entry *e;
+	size_t len = strlen(name) + 1;
+	u32 hash = jhash(name, len-1, 0);
+
+	head = &marker_table[hash & ((1 << MARKER_HASH_BITS)-1)];
Quoted 9 lines

kernel/module.c

Quoted 6 lines
kernel/module.c +6 -0
+	hlist_for_each_entry(e, node, head, hlist) {
+		if (!strcmp(name, e->name))
+			return e;
+	}
+	return NULL;
+}

OK, don't understand the strlen, len, len-1 dance here?

Let's say we have abc\0 for marker name as name input.

len = 3 + 1 = 4 (including \0)
hash is done only on the 3 first chars, excluding the \0 (therefore the
len-1 there)

Actually, it's like this only for a matter of consistency between add_marker and remove_marker, which are quite similar, but add_marker needs name_len to include the \0 value. It would be odd to change the logic between the two functions to one including the \0 and the other excluding it.

Quoted 8 lines

kernel/module.c

Quoted 5 lines
kernel/module.c +5 -0
+/*
+ * Updates the probe callback corresponding to a range of markers.
+ * Must be called with markers_mutex held.
+ */
+static void _marker_update_probe_range(

And yet:

Quoted 9 lines

kernel/module.c

Quoted 6 lines
kernel/module.c +6 -0
+void module_marker_update(struct module *mod)
+{
+	if (!mod->taints)
+		_marker_update_probe_range(mod->markers,
+			mod->markers+mod->num_markers, NULL, NULL);
+}

This doesn't hold the markers_mutex.

Since this function is only meant to be called upon module load, before the module is added to the module list, this marker range cannot be seen by other calls to marker_update_probe_range. But you are right. It also protects the hash table, so I should take the mutex there. Fixing.

Thanks for the review,

Mathieu

Quoted 3 lines

Cheers,
Rusty.

Signature · 3 lines
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
#4 lore raw

Re: [patch 1/4] Linux Kernel Markers - Architecture Independent Code

Quoted 26 lines · Mathieu Desnoyers
Quoted 18 lines · * Rusty Russell ([email protected]) wrote:
Quoted 4 lines · Mathieu Desnoyers
kernel/marker.c new file +4 -0
+{
+	struct hlist_head *head;
+	struct hlist_node *node;
+	struct marker_entry *e;

kernel/marker.c line 101

Quoted 10 lines
kernel/marker.c new file +10 -0
+	size_t len = strlen(name) + 1;
+	u32 hash = jhash(name, len-1, 0);
+
+	head = &marker_table[hash & ((1 << MARKER_HASH_BITS)-1)];
+	hlist_for_each_entry(e, node, head, hlist) {
+		if (!strcmp(name, e->name))
+			return e;
+	}
+	return NULL;
+}

OK, don't understand the strlen, len, len-1 dance here?

Let's say we have abc\0 for marker name as name input.

len = 3 + 1 = 4 (including \0)
hash is done only on the 3 first chars, excluding the \0 (therefore the
len-1 there)

Quoted 5 lines

Actually, it's like this only for a matter of consistency between add_marker and remove_marker, which are quite similar, but add_marker needs name_len to include the \0 value. It would be odd to change the logic between the two functions to one including the \0 and the other excluding it.

Sure, but that doesn't really explain why the code does:

	size_t len = strlen(name) + 1;
	u32 hash = jhash(name, len-1, 0);

Rather than:

	u32 hash = jhash(name, strlen(name), 0);
Quoted 1 line

Thanks for the review,

That's fine, just some light reading...

Cheers,
Rusty.

Quoted 1 line
author
#5 lore raw

Re: [patch 1/4] Linux Kernel Markers - Architecture Independent Code

Quoted 33 lines · * Rusty Russell ([email protected]) wrote:
Quoted 26 lines · Mathieu Desnoyers
Quoted 18 lines · * Rusty Russell ([email protected]) wrote:
Quoted 4 lines · Mathieu Desnoyers
kernel/marker.c new file +4 -0
+{
+	struct hlist_head *head;
+	struct hlist_node *node;
+	struct marker_entry *e;

kernel/marker.c line 101

Quoted 10 lines
kernel/marker.c new file +10 -0
+	size_t len = strlen(name) + 1;
+	u32 hash = jhash(name, len-1, 0);
+
+	head = &marker_table[hash & ((1 << MARKER_HASH_BITS)-1)];
+	hlist_for_each_entry(e, node, head, hlist) {
+		if (!strcmp(name, e->name))
+			return e;
+	}
+	return NULL;
+}

OK, don't understand the strlen, len, len-1 dance here?

Let's say we have abc\0 for marker name as name input.

len = 3 + 1 = 4 (including \0)
hash is done only on the 3 first chars, excluding the \0 (therefore the
len-1 there)

Quoted 5 lines

Actually, it's like this only for a matter of consistency between add_marker and remove_marker, which are quite similar, but add_marker needs name_len to include the \0 value. It would be odd to change the logic between the two functions to one including the \0 and the other excluding it.

Quoted 9 lines

Sure, but that doesn't really explain why the code does:

	size_t len = strlen(name) + 1;
	u32 hash = jhash(name, len-1, 0);

Rather than:

	u32 hash = jhash(name, strlen(name), 0);

Yup, good point. Fixed.

Thanks,

Mathieu

Quoted 8 lines
Quoted 1 line

Thanks for the review,

That's fine, just some light reading...

Cheers,
Rusty.

Quoted 1 line
Signature · 3 lines
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
author
#6 lore raw

PATCH 2/4 Linux Kernel Markers - Add kconfig menus for the marker code

In reply to Mathieu Desnoyers

With the increasing complexity of today's user-space application and the wide deployment of SMP systems, the users need an increasing understanding of the behavior and performance of a system across multiple processes/different execution contexts/multiple CPUs. In applications such as large clusters (Google, IBM), video acquisition (Autodesk), embedded real-time systems (Wind River, Monta Vista, Sony) or sysadmin/programmer-type tasks (SystemTAP from Redhat), a tool that permits tracing of kernel-user space interaction becomes necessary.

Usage of such tools have been made to successfully pinpoint problems such as:
latency issues in a user-space video acquisition application, slowdown problems in large clusters due to a switch to a different filesystems with a different cache size, abnormal Linux scheduler latency (just to name a few that I have personally investigated).

The currently existing solutions does not give a system-wide overview of what
- and when - things are happening on the system. Ptracing a program works with few processes, but quickly becomes useless when it comes to keeping track of many processes.

Bugs occuring because of bad interaction of such complex systems can be very hard to find due to the fact that they occur rarely (sometimes once a week on hundreds of machines). One can therefore only hope at having the best conditions to statistically reproduce the bug while extracting information from the system. Some bugs have been successfully found at Google using their ktrace tracer only because they could enable it on production machines and therefore recreate the same context where the bug happened.

Therefore, it makes sense to offer an instrumentation set of the most relevant events occurring in the Linux that can have the smallest performance cost possible when not active while not requiring a reboot of a production system to activate. This is essentially what the markers are providing.

Since we cannot limit the growth of the Linux kernel, nor can we pre-determine each and every "interesting" instrumentation within each subsystem and driver, it is sensible to let this task to the persons who knows the best their code. Adding instrumentation should therefore be as easy as adding and maintaining a "printk" in the kernel code from the developer's point of view.

Towards a complete tracing mechanism in the Linux kernel, the markers are only one step forward. The following step is to connect probes to those markers that will record the tracing information in buffers exported to user-space, organized in timestamped "events". Probe callbacks are responsible for serializing the information passed as parameter to the markers (described by the format string) into the events. A control mechanism to activate/stop the tracing is required, as well as a daemon that maps the buffers to write them to disk or send them through the network.

Keeping track of the events also requires a centralized infrastructure : the idea is to assign a unique ID to each event so they can be later recognized in the trace. Keeping in mind that recording the complete instrumentation site name string for each event would be more that inefficient, assigning a numeric unique identifier makes sense.

Finally, support for gathering events coming from user-space, with a minimal performance impact, is very useful to see the interaction between the system's execution contexts.

The last steps are currently implemented in Linux Trace Toolkit Next Generation (LTTng).

The SystemTAP project could clearly benefit from such an infrastructure for tracing. In addition, they would be providing support for dynamic addition of kernel probes through breakpoints/jumps when possible, with the associated restrictions (accessing local variables, reentrancy, speed).

This marker infrastructure is a hook-callback mechanism. It is meant to have an impact as low as possible on the system performances when no callback (probe) is connected so markers (hooks) can be compiled into a production kernel without noticeable slowdown.

Why use the markers instead of kprobes?

The rationale behind this mechanism the following :

1 - It makes sense to have instrumentation (for tracing, profiling)
within the kernel source tree so that it can follow its evolution. Other options, such as kprobes, imply maintaining an external set of instrumentation that must be adapted to each kernel version. Although it may make sense for distributions, it is not well suited for kernel developers, since they rarely work on a major distribution image.
2 - kprobes, although being a very good attempt at providing a dynamic
hooking mechanism that has no impact when disabled, suffers from important limitations :
a - It cannot access local variables of a function at a particular
point within its body that will be consistent thorough the kernel versions without involving a lot of recurrent hair-pulling.
b - Kprobes is slow, since it involves going though a trap each time
a probe site is executed. Even though the djprobes project made a good effort to make things faster, it cannot currently instrument fully-preemptible kernels and does not solve (1), (2a) and (2c).
c - On the reentrancy side, going though a trap (thus playing with
interrupt enable/disable) and taking spinlocks are not suited to some code paths, i.e. :
kernel/lockdep.c, printk (within the lockdep_on()/lockdep_off()). It must be understood that some code paths interesting for instrumentation often present a particular reentrancy challenge.

Some more details :

The probe callback connection to its markers is done dynamically. A predicted branch (see the immediate values infrastructure) is used to skip the hook stack setup and function call when the marker is "disabled" (no probe is connected). Further optimizations can be implemented for each architecture to make this branch faster.

Instrumentation of a subsystem becomes therefore a straightforward task. One has to add instrumentation within the key locations of the kernel code in the following form :

trace_mark(subsystem_event, "%d %p", myint, myptr);

Jim Keniston <[email protected]> adds:

kprobes remains a vital foundation for SystemTap. But markers are attactive as an alternate source of trace/debug info. Here's why:

1. Markers will live in the kernel and presumably be kept up to date by the maintainers of the enclosing code. We have a growing set of tapsets (probe libraries), each of which "knows" the source code for a certain area of the kernel. Whenever the underlying kernel code changes (e.g., a function or one of its args disappears or is renamed), there's a chance that the tapset will become invalid until we bring it back in sync with the kernel. As you can imagine, maintaining tapsets separate from the kernel source is a maintenance headache. Markers could mitigate this.

2. Because the kernel code is highly optimized, the kernel's dwarf info doesn't always accurately reflect which variables have which values on which lines (sometimes even upon entry to a function). A marker is a way to ensure that values of interest are available to SystemTap at marked points.

3. Sometimes the overhead of a kprobe probepoint is too much (either in terms of time or locking) for the particular hotspot we want to probe.

In OLS2006 proceedings, vol. 1
http://www.linuxsymposium.org/2006/linuxsymposium_procv1.pdf

Frank C. Eigler, from SystemTAP, presents its "static probing markers" (pp. 261-268) in his paper "Problem Solving With Systemtap".

He explains the advantages :

"In exchange for this effort, systemtap marker-based probes are faster and
more precise than kprobes. The better precision comes from not having to covet the compiler's favours. Such fickle favours include retaining clean boundaries in the instruction stream between interesting statements, and precisely describing positions of variables in the stack frame. Since markers don't rely on debugging information, neither favour is required, and the compiler can channel its charms into unabated optimization. The speed advantage comes from using direct call instructions rather than int 3 breakpoints to dispatch to the systemtap handlers. We will see below just how big a difference this makes."

He does a comparison of his "simple" marker solution with kprobes (his simple solution looks like my generic markers, but with a major race condition). I also posted numbers about the markers performance impact a few months ago in the initial thread. I can dig into my emails to find them for you if you consider it important for the Changelog.

He concludes with :

"To the extent that is true, we propose that these groups consider using a
shared pool of static markers as the basic kernel-side instrumentation mechanism. If they prove to have as low dormant cost and as high active performance as initial experience suggests, perhaps this could motivate the various tracing efforts and kernel subsystem developers to finally join forces. Let's designate standard trace/probe points once and for all. Tracing backends can attach to these markers the same way systemtap would. There would be no need for them to maintain kernel patches any more. Let's think about it."

This patch:

Add Kconfig menus for the marker code.

[[email protected]: Never ever select MODULES]
Signed-off-by Mathieu Desnoyers <[email protected]>
CC Adrian Bunk <[email protected]>

---

 arch/alpha/Kconfig       |    2 ++
 arch/arm/Kconfig         |    2 ++
 arch/avr32/Kconfig.debug |    7 +++++++
 arch/cris/Kconfig        |    2 ++
 arch/frv/Kconfig         |    2 ++
 arch/h8300/Kconfig       |    2 ++
 arch/i386/Kconfig        |    2 ++
 arch/ia64/Kconfig        |    2 ++
 arch/m32r/Kconfig        |    2 ++
 arch/m68k/Kconfig        |    2 ++
 arch/m68knommu/Kconfig   |    2 ++
 arch/mips/Kconfig        |    2 ++
 arch/parisc/Kconfig      |    2 ++
 arch/powerpc/Kconfig     |    2 ++
 arch/ppc/Kconfig         |    2 ++
 arch/s390/Kconfig        |    2 ++
 arch/sh/Kconfig          |    2 ++
 arch/sh64/Kconfig        |    2 ++
 arch/sparc/Kconfig       |    2 ++
 arch/sparc64/Kconfig     |    2 ++
 arch/um/Kconfig          |    2 ++
 arch/v850/Kconfig        |    2 ++
 arch/x86_64/Kconfig      |    2 ++
 arch/xtensa/Kconfig      |    2 ++
 kernel/Kconfig.marker    |    7 +++++++
 kernel/Makefile          |    1 +
 26 files changed, 61 insertions(+)
arch/alpha/Kconfig +2 -0
Index: linux-2.6-lttng/arch/alpha/Kconfig
===================================================================
@@ -646,6 +646,8 @@ config SRM_ENV
 
 source "fs/Kconfig.binfmt"
 
+source "kernel/Kconfig.marker"
+
 endmenu
 
 source "net/Kconfig"
arch/arm/Kconfig +2 -0
Index: linux-2.6-lttng/arch/arm/Kconfig
===================================================================
@@ -1052,6 +1052,8 @@ source "drivers/rtc/Kconfig"
 
 source "drivers/dma/Kconfig"
 
+source "kernel/Kconfig.marker"
+
 endmenu
 
 source "fs/Kconfig"
arch/cris/Kconfig +2 -0
Index: linux-2.6-lttng/arch/cris/Kconfig
===================================================================
@@ -151,6 +151,8 @@ source "net/Kconfig"
 menu "Drivers for built-in interfaces"
 source arch/cris/arch-v10/drivers/Kconfig
 
+source "kernel/Kconfig.marker"
+
 endmenu
 
 source "drivers/base/Kconfig"
arch/frv/Kconfig +2 -0
Index: linux-2.6-lttng/arch/frv/Kconfig
===================================================================
@@ -367,6 +367,8 @@ menu "Executable formats"
 
 source "fs/Kconfig.binfmt"
 
+source "kernel/Kconfig.marker"
+
 endmenu
 
 source "net/Kconfig"
arch/h8300/Kconfig +2 -0
Index: linux-2.6-lttng/arch/h8300/Kconfig
===================================================================
@@ -219,6 +219,8 @@ source "drivers/hwmon/Kconfig"
 
 source "drivers/usb/Kconfig"
 
+source "kernel/Kconfig.marker"
+
 endmenu
 
 source "fs/Kconfig"
arch/i386/Kconfig +2 -0
Index: linux-2.6-lttng/arch/i386/Kconfig
===================================================================
@@ -1258,6 +1258,8 @@ config KPROBES
 	  for kernel debugging, non-intrusive instrumentation and testing.
 	  If in doubt, say "N".
 
+source "kernel/Kconfig.marker"
+
 endif # INSTRUMENTATION
 
 source "arch/i386/Kconfig.debug"
arch/ia64/Kconfig +2 -0
Index: linux-2.6-lttng/arch/ia64/Kconfig
===================================================================
@@ -549,6 +549,8 @@ source "drivers/pci/hotplug/Kconfig"
 
 source "drivers/pcmcia/Kconfig"
 
+source "kernel/Kconfig.marker"
+
 endmenu
 
 endif
arch/m32r/Kconfig +2 -0
Index: linux-2.6-lttng/arch/m32r/Kconfig
===================================================================
@@ -398,6 +398,8 @@ menu "Executable file formats"
 
 source "fs/Kconfig.binfmt"
 
+source "kernel/Kconfig.marker"
+
 endmenu
 
 source "net/Kconfig"
arch/m68k/Kconfig +2 -0
Index: linux-2.6-lttng/arch/m68k/Kconfig
===================================================================
@@ -679,6 +679,8 @@ config SERIAL_CONSOLE
 
 	  If unsure, say N.
 
+source "kernel/Kconfig.marker"
+
 endmenu
 
 source "fs/Kconfig"
arch/m68knommu/Kconfig +2 -0
Index: linux-2.6-lttng/arch/m68knommu/Kconfig
===================================================================
@@ -673,6 +673,8 @@ source "drivers/pcmcia/Kconfig"
 
 source "drivers/pci/hotplug/Kconfig"
 
+source "kernel/Kconfig.marker"
+
 endmenu
 
 menu "Executable file formats"
arch/mips/Kconfig +2 -0
Index: linux-2.6-lttng/arch/mips/Kconfig
===================================================================
@@ -1947,6 +1947,8 @@ menu "Power management options"
 
 source "kernel/power/Kconfig"
 
+source "kernel/Kconfig.marker"
+
 endmenu
 
 source "net/Kconfig"
arch/parisc/Kconfig +2 -0
Index: linux-2.6-lttng/arch/parisc/Kconfig
===================================================================
@@ -259,6 +259,8 @@ menu "Executable file formats"
 
 source "fs/Kconfig.binfmt"
 
+source "kernel/Kconfig.marker"
+
 endmenu
 
 source "net/Kconfig"
arch/powerpc/Kconfig +2 -0
Index: linux-2.6-lttng/arch/powerpc/Kconfig
===================================================================
@@ -502,6 +502,8 @@ source "drivers/pcmcia/Kconfig"
 
 source "drivers/pci/hotplug/Kconfig"
 
+source "kernel/Kconfig.marker"
+
 endmenu
 
 menu "Advanced setup"
arch/ppc/Kconfig +2 -0
Index: linux-2.6-lttng/arch/ppc/Kconfig
===================================================================
@@ -1449,6 +1449,8 @@ config SERIAL_SICC_CONSOLE
 	depends on SERIAL_SICC && UART0_TTYS1
 	default y
 
+source "kernel/Kconfig.marker"
+
 endmenu
 
 source "lib/Kconfig"
arch/s390/Kconfig +2 -0
Index: linux-2.6-lttng/arch/s390/Kconfig
===================================================================
@@ -547,6 +547,8 @@ config KPROBES
 	  for kernel debugging, non-intrusive instrumentation and testing.
 	  If in doubt, say "N".
 
+source "kernel/Kconfig.marker"
+
 endmenu
 
 source "arch/s390/Kconfig.debug"
arch/sh/Kconfig +2 -0
Index: linux-2.6-lttng/arch/sh/Kconfig
===================================================================
@@ -722,6 +722,8 @@ depends on EXPERIMENTAL && SYS_SUPPORTS_
 
 source kernel/power/Kconfig
 
+source "kernel/Kconfig.marker"
+
 endmenu
 
 source "net/Kconfig"
arch/sh64/Kconfig +2 -0
Index: linux-2.6-lttng/arch/sh64/Kconfig
===================================================================
@@ -277,6 +277,8 @@ menu "Executable file formats"
 
 source "fs/Kconfig.binfmt"
 
+source "kernel/Kconfig.marker"
+
 endmenu
 
 source "net/Kconfig"
arch/sparc/Kconfig +2 -0
Index: linux-2.6-lttng/arch/sparc/Kconfig
===================================================================
@@ -316,6 +316,8 @@ config UNIX98_PTY_COUNT
 	  When not in use, each additional set of 256 PTYs occupy
 	  approximately 8 KB of kernel memory on 32-bit architectures.
 
+source "kernel/Kconfig.marker"
+
 endmenu
 
 source "fs/Kconfig"
arch/sparc64/Kconfig +2 -0
Index: linux-2.6-lttng/arch/sparc64/Kconfig
===================================================================
@@ -419,6 +419,8 @@ config SOLARIS_EMUL
 	  To compile this code as a module, choose M here: the
 	  module will be called solaris.
 
+source "kernel/Kconfig.marker"
+
 endmenu
 
 config SCHED_SMT
arch/um/Kconfig +2 -0
Index: linux-2.6-lttng/arch/um/Kconfig
===================================================================
@@ -296,6 +296,8 @@ config UML_REAL_TIME_CLOCK
 	up for the time spent at the breakpoint.  This could result in a
 	noticeable lag.  If this is a problem, then disable this option.
 
+source "kernel/Kconfig.marker"
+
 endmenu
 
 source "init/Kconfig"
arch/v850/Kconfig +2 -0
Index: linux-2.6-lttng/arch/v850/Kconfig
===================================================================
@@ -294,6 +294,8 @@ source "drivers/ide/Kconfig"
 
 source "drivers/scsi/Kconfig"
 
+source "kernel/Kconfig.marker"
+
 endmenu
 
 #############################################################################
arch/x86_64/Kconfig +2 -0
Index: linux-2.6-lttng/arch/x86_64/Kconfig
===================================================================
@@ -817,6 +817,8 @@ config SYSVIPC_COMPAT
 	depends on COMPAT && SYSVIPC
 	default y
 
+source "kernel/Kconfig.marker"
+
 endmenu
 
 source "net/Kconfig"
arch/xtensa/Kconfig +2 -0
Index: linux-2.6-lttng/arch/xtensa/Kconfig
===================================================================
@@ -226,6 +226,8 @@ config KCORE_ELF
 
 source "fs/Kconfig.binfmt"
 
+source "kernel/Kconfig.marker"
+
 endmenu
 
 source "net/Kconfig"
kernel/Kconfig.marker new file +7 -0
Index: linux-2.6-lttng/kernel/Kconfig.marker
===================================================================
@@ -0,0 +1,7 @@
+# Code markers configuration
+
+config MARKERS
+	bool "Activate markers"
+	help
+	  Place an empty function call at each marker site. Can be
+	  dynamically changed for a probe function.
arch/avr32/Kconfig.debug +7 -0
Index: linux-2.6-lttng/arch/avr32/Kconfig.debug
===================================================================
@@ -6,6 +6,9 @@ config TRACE_IRQFLAGS_SUPPORT
 
 source "lib/Kconfig.debug"
 
+menu "Instrumentation Support"
+	depends on EXPERIMENTAL
+
 config KPROBES
 	bool "Kprobes"
 	depends on DEBUG_KERNEL

@@ -16,4 +19,8 @@ config KPROBES
           for kernel debugging, non-intrusive instrumentation and testing.
           If in doubt, say "N".
 
+source "kernel/Kconfig.marker"
+
+endmenu
+
 endmenu
kernel/Makefile +1 -0
Index: linux-2.6-lttng/kernel/Makefile
===================================================================
@@ -58,6 +58,7 @@ obj-$(CONFIG_SYSCTL) += utsname_sysctl.o
 obj-$(CONFIG_TASK_DELAY_ACCT) += delayacct.o
 obj-$(CONFIG_TASKSTATS) += taskstats.o tsacct.o
 obj-$(CONFIG_IMMEDIATE) += immediate.o
+obj-$(CONFIG_MARKERS) += marker.o
 
 ifneq ($(CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER),y)
 # According to Alan Modra <[email protected]>, the -fno-omit-frame-pointer is
Signature · 3 lines
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
author
#7 lore raw

PATCH 3/4 Linux Kernel Markers - Documentation

In reply to Mathieu Desnoyers

Here is some documentation explaining what is/how to use the Linux Kernel Markers.

Signed-off-by Mathieu Desnoyers <[email protected]>

---

 Documentation/marker.txt |  257 +++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 257 insertions(+)
Documentation/marker.txt new file +257 -0
Index: linux-2.6-lttng/Documentation/marker.txt
===================================================================
@@ -0,0 +1,257 @@
+ 	             Using the Linux Kernel Markers
+
+			    Mathieu Desnoyers
+
+
+This document introduces Linux Kernel Markers and their use. It provides
+examples of how to insert markers in the kernel and connect probe functions to
+them and provides some examples of probe functions.
+
+
+* Purpose of markers
+
+A marker placed in your 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 penality (checking a condition for a branch) and space
+penality (adding a few bytes for the function call at the end of the
+instrumented function and adds a data structure in a separate section). The
+immediate values are used to minimize the impact on data cache, encoding the
+condition in the instruction stream. 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.
+
+
+* Usage
+
+In order to use the macro trace_mark, you should include linux/marker.h.
+
+#include <linux/marker.h>
+
+Add, in your code :
+
+trace_mark(subsystem_event, "%d %s", someint, somestring);
+Where :
+- subsystem_event is an identifier unique to your event
+    - subsystem is the name of your subsystem.
+    - event is the name of the event to mark.
+- "%d %s" is the formatted string for the serializer.
+- someint is an integer.
+- somestring is a char pointer.
+
+Connecting a function (probe) to a marker is done by providing a probe (function
+to call) for the specific marker through marker_probe_register() and can be
+activated by calling marker_arm(). Marker deactivation can be done by calling
+marker_disarm() as many times as marker_arm() has been called. Removing a probe
+is done through marker_probe_unregister(); it will disarm the probe and make
+sure there is no caller left using the probe when it returns. Probe removal is
+preempt-safe because preemption is disabled around the probe call. See the
+"Probe example" section below for a sample probe module.
+
+The marker mechanism supports inserting multiple instances of the same marker.
+Markers can be put in inline functions, inlined static functions, and
+unrolled loops.
+
+The naming scheme "subsystem_event" is suggested here as a convention intended
+to limit collisions. Marker names are global to the kernel: they are considered
+as being the same whether they are in the core kernel image or in modules.
+Conflicting format strings for markers with the same name will cause the markers
+to be detected to have a different format string not to be armed and will output
+a printk warning which identifies the inconsistency:
+
+"Format mismatch for probe probe_name (format), marker (format)"
+
+
+* Optimization for a given architecture
+
+One can implement optimized markers for a given architecture by replacing
+asm-$ARCH/marker.h.
+
+To force use of a non-optimized version of the markers, _trace_mark() should be
+used. It takes the same parameters as the normal markers, but it does not use
+the immediate values based on code patching.
+
+
+* Probe example
+
+You can build the kernel modules, probe-example.ko and marker-example.ko,
+using the following Makefile:
+------------------------------ CUT -------------------------------------
+obj-m := probe-example.o marker-example.o
+KDIR := /lib/modules/$(shell uname -r)/build
+PWD := $(shell pwd)
+default:
+	$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules
+clean:
+	rm -f *.mod.c *.ko *.o
+------------------------------ CUT -------------------------------------
+/* probe-example.c
+ *
+ * Connects two functions to marker call sites.
+ *
+ * (C) Copyright 2007 Mathieu Desnoyers <[email protected]>
+ *
+ * This file is released under the GPLv2.
+ * See the file COPYING for more details.
+ */
+
+#include <linux/sched.h>
+#include <linux/kernel.h>
+#include <linux/module.h>
+#include <linux/marker.h>
+#include <asm/atomic.h>
+
+struct probe_data {
+	const char *name;
+	const char *format;
+	marker_probe_func *probe_func;
+};
+
+void probe_subsystem_event(const struct __mark_marker *mdata,
+		const char *format, ...)
+{
+	va_list ap;
+	/* Declare args */
+	unsigned int value;
+	const char *mystr;
+
+	/* Assign args */
+	va_start(ap, format);
+	value = va_arg(ap, typeof(value));
+	mystr = va_arg(ap, typeof(mystr));
+
+	/* Call printk */
+	printk("Value %u, string %s\n", value, mystr);
+
+	/* or count, check rights, serialize data in a buffer */
+
+	va_end(ap);
+}
+
+atomic_t eventb_count = ATOMIC_INIT(0);
+
+void probe_subsystem_eventb(const struct __mark_marker *mdata,
+	const char *format, ...)
+{
+	/* Increment counter */
+	atomic_inc(&eventb_count);
+}
+
+static struct probe_data probe_array[] =
+{
+	{	.name = "subsystem_event",
+		.format = "%d %s",
+		.probe_func = probe_subsystem_event },
+	{	.name = "subsystem_eventb",
+		.format = MARK_NOARGS,
+		.probe_func = probe_subsystem_eventb },
+};
+
+static int __init probe_init(void)
+{
+	int result;
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(probe_array); i++) {
+		result = marker_probe_register(probe_array[i].name,
+				probe_array[i].format,
+				probe_array[i].probe_func, &probe_array[i]);
+		if (result)
+			printk(KERN_INFO "Unable to register probe %s\n",
+				probe_array[i].name);
+		result = marker_arm(probe_array[i].name);
+		if (result)
+			printk(KERN_INFO "Unable to arm probe %s\n",
+				probe_array[i].name);
+	}
+	return 0;
+}
+
+static void __exit probe_fini(void)
+{
+	int i;
+
+	for (i = 0; i < ARRAY_SIZE(probe_array); i++) {
+		marker_probe_unregister(probe_array[i].name);
+	}
+	printk("Number of event b : %u\n", atomic_read(&eventb_count));
+}
+
+module_init(probe_init);
+module_exit(probe_fini);
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Mathieu Desnoyers");
+MODULE_DESCRIPTION("SUBSYSTEM Probe");
+------------------------------ CUT -------------------------------------
+/* marker-example.c
+ *
+ * Executes a marker when /proc/marker-example is opened.
+ *
+ * (C) Copyright 2007 Mathieu Desnoyers <[email protected]>
+ *
+ * This file is released under the GPLv2.
+ * See the file COPYING for more details.
+ */
+
+#include <linux/module.h>
+#include <linux/marker.h>
+#include <linux/sched.h>
+#include <linux/proc_fs.h>
+
+struct proc_dir_entry *pentry_example = NULL;
+
+static int my_open(struct inode *inode, struct file *file)
+{
+	int i;
+
+	trace_mark(subsystem_event, "%d %s", 123, "example string");
+	for (i=0; i<10; i++) {
+		trace_mark(subsystem_eventb, MARK_NOARGS);
+	}
+	return -EPERM;
+}
+
+static struct file_operations mark_ops = {
+	.open = my_open,
+};
+
+static int example_init(void)
+{
+	printk(KERN_ALERT "example init\n");
+	pentry_example = create_proc_entry("marker-example", 0444, NULL);
+	if (pentry_example)
+		pentry_example->proc_fops = &mark_ops;
+	else
+		return -EPERM;
+	return 0;
+}
+
+static void example_exit(void)
+{
+	printk(KERN_ALERT "example exit\n");
+	remove_proc_entry("marker-example", NULL);
+}
+
+module_init(example_init)
+module_exit(example_exit)
+
+MODULE_LICENSE("GPL");
+MODULE_AUTHOR("Mathieu Desnoyers");
+MODULE_DESCRIPTION("Linux Trace Toolkit example");
+------------------------------ CUT -------------------------------------
+Sequence of operations : (as root)
+make
+insmod marker-example.ko (insmod order is not important)
+insmod probe-example.ko
+cat /proc/marker-example (returns an expected error)
+rmmod marker-example probe-example
+dmesg
+------------------------------ CUT -------------------------------------
Signature · 3 lines
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
#8 lore raw

Re: [patch 3/4] Linux Kernel Markers - Documentation

Quoted 2 lines · Mathieu Desnoyers

Here is some documentation explaining what is/how to use the Linux Kernel Markers.

While porting my code from an older markers version I noticed the marker callbacks have grown a void *private argument. Add it to the documentation aswell.

Signed-off-by Christoph Hellwig <[email protected]>
Documentation/marker.txt +1 -1
Index: linux-2.6/Documentation/marker.txt
===================================================================
@@ -115,7 +115,7 @@ struct probe_data {
 };
 
 void probe_subsystem_event(const struct __mark_marker *mdata,
-		const char *format, ...)
+		void *private, const char *format, ...)
 {
 	va_list ap;
 	/* Declare args */
author
#9 lore raw

Re: [patch 3/4] Linux Kernel Markers - Documentation

Quoted 11 lines · * Christoph Hellwig ([email protected]) wrote:
Quoted 2 lines · Mathieu Desnoyers

Here is some documentation explaining what is/how to use the Linux Kernel Markers.

While porting my code from an older markers version I noticed the marker callbacks have grown a void *private argument. Add it to the documentation aswell.

Signed-off-by Christoph Hellwig <[email protected]>
Signed-off-by Mathieu Desnoyers <[email protected]>

Thanks!

Quoted 13 lines

Index: linux-2.6/Documentation/marker.txt
===================================================================

Documentation/marker.txt +1 -1
@@ -115,7 +115,7 @@ struct probe_data {
 };
 
 void probe_subsystem_event(const struct __mark_marker *mdata,
-		const char *format, ...)
+		void *private, const char *format, ...)
 {
 	va_list ap;
 	/* Declare args */
Signature · 3 lines
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
author
#10 lore raw

PATCH 4/4 Port of blktrace to the Linux Kernel Markers.

In reply to Mathieu Desnoyers

Here is the first stage of a port of blktrace to the Linux Kernel Markers. The advantage of this port is that it minimizes the impact on the running when blktrace is not active.

A few remarks : this patch has the positive effect of removing some code from the block io tracing hot paths, minimizing the i-cache impact in a system where the io tracing is compiled in but inactive.

It also moves the blk tracing code from a header (and therefore from the body of the instrumented functions) to a separate C file.

There, as soon as one device has to be traced, all devices have to execute the tracing function call when they pass by the instrumentation site. This is slower than the previous inline function which tested the condition quickly.

It does not make the code smaller, since I left all the specialized tracing functions for requests, bio, generic, remap, which would go away once a generic infrastructure is in place to serialize the information passed to the marker. This is mostly why I consider it as a step towards the full improvements that could bring the markers.

Signed-off-by Mathieu Desnoyers <[email protected]>
CC Jens Axboe <[email protected]>

---

 block/Kconfig                |    1 
 block/blktrace.c             |  342 ++++++++++++++++++++++++++++++++++++++++++-
 block/elevator.c             |    6 
 block/ll_rw_blk.c            |   28 +--
 drivers/block/cciss.c        |    4 
 drivers/md/dm.c              |   14 -
 fs/bio.c                     |    6 
 include/linux/blktrace_api.h |  144 +-----------------
 mm/bounce.c                  |    4 
 mm/highmem.c                 |    2 
 10 files changed, 383 insertions(+), 168 deletions(-)
block/elevator.c +3 -3
Index: linux-2.6-lttng/block/elevator.c
===================================================================
@@ -32,7 +32,7 @@
 #include <linux/init.h>
 #include <linux/compiler.h>
 #include <linux/delay.h>
-#include <linux/blktrace_api.h>
+#include <linux/marker.h>
 #include <linux/hash.h>
 
 #include <asm/uaccess.h>

@@ -548,7 +548,7 @@ void elv_insert(struct request_queue *q,
 	unsigned ordseq;
 	int unplug_it = 1;
 
-	blk_add_trace_rq(q, rq, BLK_TA_INSERT);
+	trace_mark(blk_request_insert, "%p %p", q, rq);
 
 	rq->q = q;
 

@@ -727,7 +727,7 @@ struct request *elv_next_request(struct 
 			 * not be passed by new incoming requests
 			 */
 			rq->cmd_flags |= REQ_STARTED;
-			blk_add_trace_rq(q, rq, BLK_TA_ISSUE);
+			trace_mark(blk_request_issue, "%p %p", q, rq);
 		}
 
 		if (!q->boundary_rq || q->boundary_rq == rq) {
block/ll_rw_blk.c +15 -13
Index: linux-2.6-lttng/block/ll_rw_blk.c
===================================================================
@@ -28,6 +28,7 @@
 #include <linux/task_io_accounting_ops.h>
 #include <linux/interrupt.h>
 #include <linux/cpu.h>
+#include <linux/marker.h>
 #include <linux/blktrace_api.h>
 #include <linux/fault-inject.h>
 

@@ -1555,7 +1556,7 @@ void blk_plug_device(struct request_queu
 
 	if (!test_and_set_bit(QUEUE_FLAG_PLUGGED, &q->queue_flags)) {
 		mod_timer(&q->unplug_timer, jiffies + q->unplug_delay);
-		blk_add_trace_generic(q, NULL, 0, BLK_TA_PLUG);
+		trace_mark(blk_plug_device, "%p %p %d", q, NULL, 0);
 	}
 }
 

@@ -1621,7 +1622,7 @@ static void blk_backing_dev_unplug(struc
 	 * devices don't necessarily have an ->unplug_fn defined
 	 */
 	if (q->unplug_fn) {
-		blk_add_trace_pdu_int(q, BLK_TA_UNPLUG_IO, NULL,
+		trace_mark(blk_pdu_unplug_io, "%p %p %d", q, NULL,
 					q->rq.count[READ] + q->rq.count[WRITE]);
 
 		q->unplug_fn(q);

@@ -1633,7 +1634,7 @@ static void blk_unplug_work(struct work_
 	struct request_queue *q =
 		container_of(work, struct request_queue, unplug_work);
 
-	blk_add_trace_pdu_int(q, BLK_TA_UNPLUG_IO, NULL,
+	trace_mark(blk_pdu_unplug_io, "%p %p %d", q, NULL,
 				q->rq.count[READ] + q->rq.count[WRITE]);
 
 	q->unplug_fn(q);

@@ -1643,7 +1644,7 @@ static void blk_unplug_timeout(unsigned 
 {
 	struct request_queue *q = (struct request_queue *)data;
 
-	blk_add_trace_pdu_int(q, BLK_TA_UNPLUG_TIMER, NULL,
+	trace_mark(blk_pdu_unplug_timer, "%p %p %d", q, NULL,
 				q->rq.count[READ] + q->rq.count[WRITE]);
 
 	kblockd_schedule_work(&q->unplug_work);

@@ -2156,7 +2157,7 @@ rq_starved:
 	
 	rq_init(q, rq);
 
-	blk_add_trace_generic(q, bio, rw, BLK_TA_GETRQ);
+	trace_mark(blk_get_request, "%p %p %d", q, bio, rw);
 out:
 	return rq;
 }

@@ -2186,7 +2187,7 @@ static struct request *get_request_wait(
 		if (!rq) {
 			struct io_context *ioc;
 
-			blk_add_trace_generic(q, bio, rw, BLK_TA_SLEEPRQ);
+			trace_mark(blk_sleep_request, "%p %p %d", q, bio, rw);
 
 			__generic_unplug_device(q);
 			spin_unlock_irq(q->queue_lock);

@@ -2260,7 +2261,7 @@ EXPORT_SYMBOL(blk_start_queueing);
  */
 void blk_requeue_request(struct request_queue *q, struct request *rq)
 {
-	blk_add_trace_rq(q, rq, BLK_TA_REQUEUE);
+	trace_mark(blk_requeue, "%p %p", q, rq);
 
 	if (blk_rq_tagged(rq))
 		blk_queue_end_tag(q, rq);

@@ -2948,7 +2949,7 @@ static int __make_request(struct request
 			if (!ll_back_merge_fn(q, req, bio))
 				break;
 
-			blk_add_trace_bio(q, bio, BLK_TA_BACKMERGE);
+			trace_mark(blk_bio_backmerge, "%p %p", q, bio);
 
 			req->biotail->bi_next = bio;
 			req->biotail = bio;

@@ -2965,7 +2966,7 @@ static int __make_request(struct request
 			if (!ll_front_merge_fn(q, req, bio))
 				break;
 
-			blk_add_trace_bio(q, bio, BLK_TA_FRONTMERGE);
+			trace_mark(blk_bio_frontmerge, "%p %p", q, bio);
 
 			bio->bi_next = req->bio;
 			req->bio = bio;

@@ -3195,10 +3196,11 @@ end_io:
 		blk_partition_remap(bio);
 
 		if (old_sector != -1)
-			blk_add_trace_remap(q, bio, old_dev, bio->bi_sector, 
-					    old_sector);
+			trace_mark(blk_remap, "%p %p %llu %llu %llu",
+					q, bio, (u64)old_dev,
+					(u64)bio->bi_sector, (u64)old_sector);
 
-		blk_add_trace_bio(q, bio, BLK_TA_QUEUE);
+		trace_mark(blk_bio_queue, "%p %p", q, bio);
 
 		old_sector = bio->bi_sector;
 		old_dev = bio->bi_bdev->bd_dev;

@@ -3391,7 +3393,7 @@ static int __end_that_request_first(stru
 	int total_bytes, bio_nbytes, error, next_idx = 0;
 	struct bio *bio;
 
-	blk_add_trace_rq(req->q, req, BLK_TA_COMPLETE);
+	trace_mark(blk_request_complete, "%p %p", req->q, req);
 
 	/*
 	 * extend uptodate bool to allow < 0 value to be direct io error
block/Kconfig +1 -0
Index: linux-2.6-lttng/block/Kconfig
===================================================================
@@ -32,6 +32,7 @@ config BLK_DEV_IO_TRACE
 	depends on SYSFS
 	select RELAY
 	select DEBUG_FS
+	select MARKERS
 	help
 	  Say Y here, if you want to be able to trace the block layer actions
 	  on a given queue. Tracing allows you to see any traffic happening
block/blktrace.c +340 -2

379 lines not on this page · raw message

include/linux/blktrace_api.h +9 -135

164 lines not on this page · raw message

mm/bounce.c +2 -2
Index: linux-2.6-lttng/mm/bounce.c
===================================================================
@@ -13,7 +13,7 @@
 #include <linux/init.h>
 #include <linux/hash.h>
 #include <linux/highmem.h>
-#include <linux/blktrace_api.h>
+#include <linux/marker.h>
 #include <asm/tlbflush.h>
 
 #define POOL_SIZE	64

@@ -237,7 +237,7 @@ static void __blk_queue_bounce(struct re
 	if (!bio)
 		return;
 
-	blk_add_trace_bio(q, *bio_orig, BLK_TA_BOUNCE);
+	trace_mark(blk_bio_bounce, "%p %p", q, *bio_orig);
 
 	/*
 	 * at least one page was bounced, fill in possible non-highmem
mm/highmem.c +1 -1
Index: linux-2.6-lttng/mm/highmem.c
===================================================================
@@ -26,7 +26,7 @@
 #include <linux/init.h>
 #include <linux/hash.h>
 #include <linux/highmem.h>
-#include <linux/blktrace_api.h>
+#include <linux/marker.h>
 #include <asm/tlbflush.h>
 
 /*
fs/bio.c +3 -3
Index: linux-2.6-lttng/fs/bio.c
===================================================================
@@ -25,7 +25,7 @@
 #include <linux/module.h>
 #include <linux/mempool.h>
 #include <linux/workqueue.h>
-#include <linux/blktrace_api.h>
+#include <linux/marker.h>
 #include <scsi/sg.h>		/* for struct sg_iovec */
 
 #define BIO_POOL_SIZE 2

@@ -1081,8 +1081,8 @@ struct bio_pair *bio_split(struct bio *b
 	if (!bp)
 		return bp;
 
-	blk_add_trace_pdu_int(bdev_get_queue(bi->bi_bdev), BLK_TA_SPLIT, bi,
-				bi->bi_sector + first_sectors);
+	trace_mark(blk_pdu_split, "%p %p %llu", bdev_get_queue(bi->bi_bdev), bi,
+				(u64)bi->bi_sector + first_sectors);
 
 	BUG_ON(bi->bi_vcnt != 1);
 	BUG_ON(bi->bi_idx != 0);
drivers/block/cciss.c +2 -2
Index: linux-2.6-lttng/drivers/block/cciss.c
===================================================================
@@ -37,7 +37,7 @@
 #include <linux/hdreg.h>
 #include <linux/spinlock.h>
 #include <linux/compat.h>
-#include <linux/blktrace_api.h>
+#include <linux/marker.h>
 #include <asm/uaccess.h>
 #include <asm/io.h>
 

@@ -2504,7 +2504,7 @@ after_error_processing:
 	}
 	cmd->rq->data_len = 0;
 	cmd->rq->completion_data = cmd;
-	blk_add_trace_rq(cmd->rq->q, cmd->rq, BLK_TA_COMPLETE);
+	trace_mark(blk_request_complete, "%p %p", cmd->rq->q, cmd->rq);
 	blk_complete_request(cmd->rq);
 }
drivers/md/dm.c +7 -7
Index: linux-2.6-lttng/drivers/md/dm.c
===================================================================
@@ -19,7 +19,7 @@
 #include <linux/slab.h>
 #include <linux/idr.h>
 #include <linux/hdreg.h>
-#include <linux/blktrace_api.h>
+#include <linux/marker.h>
 #include <linux/smp_lock.h>
 
 #define DM_MSG_PREFIX "core"

@@ -481,8 +481,8 @@ static void dec_pending(struct dm_io *io
 			wake_up(&io->md->wait);
 
 		if (io->error != DM_ENDIO_REQUEUE) {
-			blk_add_trace_bio(io->md->queue, io->bio,
-					  BLK_TA_COMPLETE);
+			trace_mark(blk_request_complete, "%p %p",
+				io->md->queue, io->bio);
 
 			bio_endio(io->bio, io->bio->bi_size, io->error);
 		}

@@ -578,10 +578,10 @@ static void __map_bio(struct dm_target *
 	r = ti->type->map(ti, clone, &tio->info);
 	if (r == DM_MAPIO_REMAPPED) {
 		/* the bio has been remapped so dispatch it */
-
-		blk_add_trace_remap(bdev_get_queue(clone->bi_bdev), clone,
-				    tio->io->bio->bi_bdev->bd_dev, sector,
-				    clone->bi_sector);
+		trace_mark(blk_remap, "%p %p %llu %llu %llu",
+			bdev_get_queue(clone->bi_bdev), clone,
+			(u64)tio->io->bio->bi_bdev->bd_dev, (u64)sector,
+			(u64)clone->bi_sector);
 
 		generic_make_request(clone);
 	} else if (r < 0 || r == DM_MAPIO_REQUEUE) {
Signature · 3 lines
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68