Linux Kernel Markers (redux)
Subsystems (20)
cover Linux Kernel Markers (redux)
Hi Andrew,
Following Christoph Hellwig's suggestion, aiming at a Linux Kernel Markers inclusion for 2.6.24, I made a simplified version of the Linux Kernel Markers. There are no more dependencies on any other patchset.
The modification only involved turning the immediate values into static variables and adapting the documentation accordingly. It will have a little more data cache impact when disabled than the version based on the immediate values, but it is far less complex.
Since things have not moved much in the markers area recently (most of the concerns were about the immediate values), I expect it to be ready for 2.6.24.
It applies to 2.6.23-rc7-mm1
Patches apply in this order:
seq_file_sorted.patch module.c-sort-module-list.patch kconfig-instrumentation.patch linux-kernel-markers-architecture-independent-code.patch linux-kernel-markers-instrumentation-menu.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
PATCH 1/7 Seq_file add support for sorted list
Add support for sorted list in seq_file. It aims at changing the way /proc/modules and kallsyms iterates on the module list to remove a race between module unload and module/symbol listing.
The list is sorted by ascending list_head pointer address.
Changelog:
When reading the data by small chunks (i.e. byte by byte), the index (ppos) is incremented by seq_read() directly and no "next" callback is called when going to the next module.
Therefore, use ppos instead of m->private to deal with the fact that this index is incremented directly to pass to the next module in seq_read() after the buffer has been emptied.
--- fs/seq_file.c | 47 +++++++++++++++++++++++++++++++++++++++++++++++ include/linux/seq_file.h | 20 ++++++++++++++++++++ 2 files changed, 67 insertions(+)
fs/seq_file.c +47 -0
@@ -510,3 +510,50 @@ struct list_head *seq_list_next(void *v, }EXPORT_SYMBOL (seq_list_next); + +struct list_head *seq_sorted_list_start (struct list_head *head,loff_t *ppos) +{ +struct list_head *lh; + +list_for_each (lh, head) +if ((unsigned long )lh >= *ppos) { + *ppos = (unsigned long )lh; +return lh; + } +return NULL ; +} + +EXPORT_SYMBOL (seq_sorted_list_start); + +struct list_head *seq_sorted_list_start_head (struct list_head *head, +loff_t *ppos) +{ +struct list_head *lh; + +if (!*ppos) { + *ppos = (unsigned long )head; +return head; + } +list_for_each (lh, head) +if ((unsigned long )lh >= *ppos) { + *ppos = (long )lh->prev; +return lh->prev; + } +return NULL ; +} + +EXPORT_SYMBOL (seq_sorted_list_start_head); + +struct list_head *seq_sorted_list_next (void *p,struct list_head *head, +loff_t *ppos) +{ +struct list_head *lh; +void *next; + + lh = ((struct list_head *)p)->next; + next = (lh == head) ?NULL : lh; + *ppos = next ? (unsigned long )next :-1UL ; +return next; +} + +EXPORT_SYMBOL (seq_sorted_list_next);
include/linux/seq_file.h +20 -0
@@ -63,5 +63,25 @@ extern struct list_head *seq_list_start_extern struct list_head *seq_list_next (void *v,struct list_head *head,loff_t *ppos); +/* +* Helpers for iteration over a list sorted by ascending head pointer address. +* To be used in contexts where preemption cannot be disabled to insure to +* continue iteration on a modified list starting at the same location where it +* stopped, or at a following location. It insures that the lost information +* will only be in elements added/removed from the list between iterations. +* void *pos is only used to get the next list element and may not be a valid +* list_head anymore when given to seq_sorted_list_start() or +* seq_sorted_list_start_head(). +*/ +extern struct list_head *seq_sorted_list_start (struct list_head *head, +loff_t *ppos); +extern struct list_head *seq_sorted_list_start_head (struct list_head *head, +loff_t *ppos); +/* +* next must be called with an existing p node +*/ +extern struct list_head *seq_sorted_list_next (void *p,struct list_head *head, +loff_t *ppos); +#endif #endif
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
Re: [patch 1/7] Seq_file add support for sorted list
Quoted 5 lines · Mathieu Desnoyers
Add support for sorted list in
seq_file. It aims at changing the way/proc/modulesand kallsyms iterates on the module list to remove a race between module unload and module/symbol listing.The list is sorted by ascending
list_headpointer address.
While I think we really want this patch I don't quite see how it's related to the markers. I think patch 1 and 2 stand on their own.
Re: [patch 1/7] Seq_file add support for sorted list
Quoted 10 lines · * Christoph Hellwig ([email protected]) wrote:
Quoted 5 lines · Mathieu Desnoyers
Add support for sorted list in
seq_file. It aims at changing the way/proc/modulesand kallsyms iterates on the module list to remove a race between module unload and module/symbol listing.The list is sorted by ascending
list_headpointer address.While I think we really want this patch I don't quite see how it's related to the markers. I think patch 1 and 2 stand on their own.
As they are currently implemented, the markers use the sorted module list for marker listing, but I can change their implementation so they do not require this (and make it a subsequent patch instead).
I could do that to diminish the patchset size a little more. However, it implies using an interface with a known race condition. Could we just post this as two different patchsets instead ? I really think the sorted module list would be important to get in and I don't like to use buggy unfixed lower level functions.
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
Re: [patch 1/7] Seq_file add support for sorted list
Quoted 9 lines · Mathieu Desnoyers
As they are currently implemented, the markers use the sorted module list for marker listing, but I can change their implementation so they do not require this (and make it a subsequent patch instead).
I could do that to diminish the patchset size a little more. However, it implies using an interface with a known race condition. Could we just post this as two different patchsets instead ? I really think the sorted module list would be important to get in and I don't like to use buggy unfixed lower level functions.
Given that we want to fix the the race I think keeping it as-is is fine. I didn't realize you depend on the new behaviour.
PATCH 2/7 Sort module list by pointer address to get coherent sleepable seq_file iterators
In reply to Mathieu DesnoyersA race that appears both in /proc/modules and in kallsyms: if, between the seq file reads, the process is put to sleep and at this moment a module is or removed from the module list, the listing will skip an amount of modules/symbols corresponding to the amount of elements present in the unloaded module, but at the current position in the list if the iteration is located after the removed module.
The cleanest way I found to deal with this problem is to sort the module list. We can then keep the old struct module * as the old iterator, knowing the it may be removed between the seq file reads, but we only use it as "get next". If it is not present in the module list, the next pointer will be used.
By doing this, removing a given module will now only fuzz the output related to this specific module, not any random module anymore. Since modprobe uses /proc/modules, it might be important to make sure multiple concurrent running modprobes won't interfere with each other.
Small test program for this:
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#define BUFSIZE 1024
int main()
{
int fd = open("/proc/modules", O_RDONLY);
char buf[BUFSIZE];
ssize_t size;
do {
size = read(fd, buf, 1);
printf("%c", buf[0]);
usleep(100000);
} while(size > 0);
close(fd);
return 0;
}Actual test (kernel 2.6.23-rc3):
dijkstra:~# lsmod Module Size Used by pl2303 18564 0 usbserial 29032 1 pl2303 ppdev 7844 0 sky2 37476 0 skge 36368 0 rtc 10104 0 snd_hda_intel 265628 0
(here, while we are printing the 2nd line, I rmmod pl2303)
compudj@dijkstra:~/test$ ./module pl2303 18564 0 - Live 0xf886e000 usbserial 29032 1 pl2303, Live 0xf8865000 sky2 37476 0 - Live 0xf884f000 skge 36368 0 - Live 0xf8838000 rtc 10104 0 - Live 0xf8825000
We see the the 2nd line is garbage.
Now, with my patch applied:
(here, while we are printing the rtc module, I rmmod rtc)nd_hda_intel 268708 0 - Live 0xf8820000 ltt_control 2372 0 - Live 0xf8866000
rtc 10392 0 - Live 0xf886d000
skge 36768 0 - Live 0xf8871000ltt_statedump 8516 0 - Live 0xf887b000
We see that since the rtc line was already in the buffer, it has been printed completely.
(here, while we are printing the skge module, I rmmod rtc)snd_hda_intel 268708 0 - Live 0xf8820000 ltt_control 2372 0 - Live 0xf8866000
rtc 10392 0 - Live 0xf886d000
skge 36768 0 - Live 0xf8871000ltt_statedump 8516 0 - Live 0xf887b000
sky2 38420 0 - Live 0xf88cd000
We see that the iteration continued at the same position even though the rtc module, located in earlier addresses, was removed.
Changelog:
When reading the data by small chunks (i.e. byte by byte), the index (ppos) is incremented by seq_read() directly and no "next" callback is called when going to the next module.
Therefore, use ppos instead of m->private to deal with the fact that this index is incremented directly to pass to the next module in seq_read() after the buffer has been emptied.
Before fix, it prints the first module indefinitely. The patch fixes this.
Changelog:
- Remove module_mutex usage: depend on functions implemented in module.c for that.
--- kernel/module.c | 23 +++++++++++++++++++---- 1 file changed, 19 insertions(+), 4 deletions(-)
kernel/module.c +19 -4
@@ -63,7 +63,8 @@ extern int module_sysfs_initialized;#define INIT_OFFSET_MASK (1UL << (BITS_PER_LONG-1))/* List of modules, protected by module_mutex or preempt_disable -* (add/delete uses stop_machine). */ +* (add/delete uses stop_machine). Sorted by ascending list node address. +*/ static DEFINE_MUTEX (module_mutex);static LIST_HEAD (modules);static DECLARE_MUTEX (notify_mutex);
@@ -2116,10 +2117,24 @@ nomodsectinfo:/* * link the module with the whole machine is stopped with interrupts off * - this defends against kallsyms not taking locks +* We sort the modules by struct module pointer address to permit correct +* iteration over modules of, at least, kallsyms for preemptible operations, +* such as read(). Sorting by struct module pointer address is equivalent to +* sort by list node address. */ static int __link_module (void *_mod) { -struct module *mod = _mod; +struct module *mod = _mod, *iter; + +list_for_each_entry_reverse (iter, &modules, list) { +BUG_ON (iter == mod);/* Should never be in the list twice */ +if (iter < mod) { +/* We belong to the location right after iter. */ +list_add (&mod->list, &iter->list); +return 0 ; + } + } +/* We should be added at the head of the list */ list_add (&mod->list, &modules);return 0 ; }
@@ -2384,12 +2399,12 @@ unsigned long module_kallsyms_lookup_namstatic void *m_start (struct seq_file *m,loff_t *pos) {mutex_lock (&module_mutex); -return seq_list_start (&modules, *pos); +return seq_sorted_list_start (&modules, pos); }static void *m_next (struct seq_file *m,void *p,loff_t *pos) { -return seq_list_next (p, &modules, pos); +return seq_sorted_list_next (p, &modules, pos); }static void m_stop (struct seq_file *m,void *p)
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
PATCH 3/7 Combine instrumentation menus in kernel/Kconfig.instrumentation
In reply to Mathieu DesnoyersQuoting Randy:
"It seems sad that this patch sources Kconfig.marker, a 7-line file, 20-something times. Yes, you (we) don't want to put those 7 lines into 20-something different files, so sourcing is the right thing.
However, what you did for avr32 seems more on the right track to me:
make _one_ Instrumentation support menu that includes PROFILING, OPROFILE, KPROBES, and MARKERS and then use (source) that in all of the arches."
--- arch/alpha/Kconfig | 2 - arch/alpha/oprofile/Kconfig | 23 ---------------------- arch/arm/Kconfig | 2 - arch/arm/oprofile/Kconfig | 42 ----------------------------------------- arch/blackfin/Kconfig | 2 - arch/blackfin/oprofile/Kconfig | 29 ---------------------------- arch/cris/Kconfig | 2 + arch/frv/Kconfig | 2 + arch/h8300/Kconfig | 2 + arch/i386/Kconfig | 25 ------------------------ arch/i386/oprofile/Kconfig | 17 ---------------- arch/ia64/Kconfig | 15 -------------- arch/ia64/oprofile/Kconfig | 20 ------------------- arch/m32r/Kconfig | 2 - arch/m32r/oprofile/Kconfig | 23 ---------------------- arch/m68k/Kconfig | 2 + arch/m68knommu/Kconfig | 2 + arch/mips/Kconfig | 2 - arch/mips/oprofile/Kconfig | 23 ---------------------- arch/parisc/Kconfig | 2 - arch/parisc/oprofile/Kconfig | 23 ---------------------- arch/powerpc/Kconfig | 15 -------------- arch/powerpc/oprofile/Kconfig | 24 ----------------------- arch/ppc/Kconfig | 2 - arch/s390/Kconfig | 16 --------------- arch/s390/oprofile/Kconfig | 22 --------------------- arch/sh/Kconfig | 2 - arch/sh/oprofile/Kconfig | 23 ---------------------- arch/sh64/Kconfig | 2 - arch/sh64/oprofile/Kconfig | 23 ---------------------- arch/sparc/Kconfig | 6 ----- arch/sparc/oprofile/Kconfig | 17 ---------------- arch/sparc64/Kconfig | 15 -------------- arch/sparc64/oprofile/Kconfig | 17 ---------------- arch/um/Kconfig | 2 + arch/v850/Kconfig | 2 + arch/x86_64/Kconfig | 15 -------------- arch/x86_64/oprofile/Kconfig | 17 ---------------- arch/xtensa/Kconfig | 2 + kernel/Kconfig.instrumentation | 40 +++++++++++++++++++++++++++++++++++++++ 40 files changed, 72 insertions(+), 452 deletions(-)
arch/alpha/oprofile/Kconfig deleted +0 -23
@@ -1,23 +0,0 @@ - -menu "Profiling support" - depends on EXPERIMENTAL - -config PROFILING - bool "Profiling support (EXPERIMENTAL)" - help - Say Y here to enable the extended profiling support mechanisms used - by profilers such as OProfile. - - -config OPROFILE - tristate "OProfile system profiling (EXPERIMENTAL)" - depends on PROFILING - help - OProfile is a profiling system capable of profiling the - whole system, include the kernel, kernel modules, libraries, - and applications. - - If unsure, say N. - -endmenu -
arch/arm/oprofile/Kconfig deleted +0 -42
42 lines not on this page · raw message
arch/blackfin/oprofile/Kconfig deleted +0 -29
@@ -1,29 +0,0 @@ -menu "Profiling support" -depends on EXPERIMENTAL - -config PROFILING - bool "Profiling support (EXPERIMENTAL)" - help - Say Y here to enable the extended profiling support mechanisms used - by profilers such as OProfile. - -config OPROFILE - tristate "OProfile system profiling (EXPERIMENTAL)" - depends on PROFILING - help - OProfile is a profiling system capable of profiling the - whole system, include the kernel, kernel modules, libraries, - and applications. - - If unsure, say N. - -config HARDWARE_PM - tristate "Hardware Performance Monitor Profiling" - depends on PROFILING - help - take use of hardware performance monitor to profiling the kernel - and application. - - If unsure, say N. - -endmenu
arch/i386/oprofile/Kconfig deleted +0 -17
@@ -1,17 +0,0 @@ -config PROFILING - bool "Profiling support (EXPERIMENTAL)" - help - Say Y here to enable the extended profiling support mechanisms used - by profilers such as OProfile. - - -config OPROFILE - tristate "OProfile system profiling (EXPERIMENTAL)" - depends on PROFILING - help - OProfile is a profiling system capable of profiling the - whole system, include the kernel, kernel modules, libraries, - and applications. - - If unsure, say N. -
arch/ia64/oprofile/Kconfig deleted +0 -20
@@ -1,20 +0,0 @@ -config PROFILING - bool "Profiling support (EXPERIMENTAL)" - help - Say Y here to enable the extended profiling support mechanisms used - by profilers such as OProfile. - -config OPROFILE - tristate "OProfile system profiling (EXPERIMENTAL)" - depends on PROFILING - help - OProfile is a profiling system capable of profiling the - whole system, include the kernel, kernel modules, libraries, - and applications. - - Due to firmware bugs, you may need to use the "nohalt" boot - option if you're using OProfile with the hardware performance - counters. - - If unsure, say N. -
arch/m32r/oprofile/Kconfig deleted +0 -23
@@ -1,23 +0,0 @@ - -menu "Profiling support" - depends on EXPERIMENTAL - -config PROFILING - bool "Profiling support (EXPERIMENTAL)" - help - Say Y here to enable the extended profiling support mechanisms used - by profilers such as OProfile. - - -config OPROFILE - tristate "OProfile system profiling (EXPERIMENTAL)" - depends on PROFILING - help - OProfile is a profiling system capable of profiling the - whole system, include the kernel, kernel modules, libraries, - and applications. - - If unsure, say N. - -endmenu -
arch/mips/oprofile/Kconfig deleted +0 -23
@@ -1,23 +0,0 @@ - -menu "Profiling support" - depends on EXPERIMENTAL - -config PROFILING - bool "Profiling support (EXPERIMENTAL)" - help - Say Y here to enable the extended profiling support mechanisms used - by profilers such as OProfile. - - -config OPROFILE - tristate "OProfile system profiling (EXPERIMENTAL)" - depends on PROFILING && !MIPS_MT_SMTC && EXPERIMENTAL - help - OProfile is a profiling system capable of profiling the - whole system, include the kernel, kernel modules, libraries, - and applications. - - If unsure, say N. - -endmenu -
arch/parisc/oprofile/Kconfig deleted +0 -23
@@ -1,23 +0,0 @@ - -menu "Profiling support" - depends on EXPERIMENTAL - -config PROFILING - bool "Profiling support (EXPERIMENTAL)" - help - Say Y here to enable the extended profiling support mechanisms used - by profilers such as OProfile. - - -config OPROFILE - tristate "OProfile system profiling (EXPERIMENTAL)" - depends on PROFILING - help - OProfile is a profiling system capable of profiling the - whole system, include the kernel, kernel modules, libraries, - and applications. - - If unsure, say N. - -endmenu -
arch/powerpc/oprofile/Kconfig deleted +0 -24
@@ -1,24 +0,0 @@ -config PROFILING - bool "Profiling support (EXPERIMENTAL)" - help - Say Y here to enable the extended profiling support mechanisms used - by profilers such as OProfile. - - -config OPROFILE - tristate "OProfile system profiling (EXPERIMENTAL)" - depends on PROFILING - help - OProfile is a profiling system capable of profiling the - whole system, include the kernel, kernel modules, libraries, - and applications. - - If unsure, say N. - -config OPROFILE_CELL - bool "OProfile for Cell Broadband Engine" - depends on (SPU_FS = y && OPROFILE = m) || (SPU_FS = y && OPROFILE = y) || (SPU_FS = m && OPROFILE = m) - default y - help - Profiling of Cell BE SPUs requires special support enabled - by this option.
arch/s390/oprofile/Kconfig deleted +0 -22
@@ -1,22 +0,0 @@ - -menu "Profiling support" - -config PROFILING - bool "Profiling support" - help - Say Y here to enable profiling support mechanisms used by - profilers such as readprofile or OProfile. - - -config OPROFILE - tristate "OProfile system profiling" - depends on PROFILING - help - OProfile is a profiling system capable of profiling the - whole system, include the kernel, kernel modules, libraries, - and applications. - - If unsure, say N. - -endmenu -
arch/sh/oprofile/Kconfig deleted +0 -23
@@ -1,23 +0,0 @@ - -menu "Profiling support" - depends on EXPERIMENTAL - -config PROFILING - bool "Profiling support (EXPERIMENTAL)" - help - Say Y here to enable the extended profiling support mechanisms used - by profilers such as OProfile. - - -config OPROFILE - tristate "OProfile system profiling (EXPERIMENTAL)" - depends on PROFILING - help - OProfile is a profiling system capable of profiling the - whole system, include the kernel, kernel modules, libraries, - and applications. - - If unsure, say N. - -endmenu -
arch/sh64/oprofile/Kconfig deleted +0 -23
@@ -1,23 +0,0 @@ - -menu "Profiling support" - depends on EXPERIMENTAL - -config PROFILING - bool "Profiling support (EXPERIMENTAL)" - help - Say Y here to enable the extended profiling support mechanisms used - by profilers such as OProfile. - - -config OPROFILE - tristate "OProfile system profiling (EXPERIMENTAL)" - depends on PROFILING - help - OProfile is a profiling system capable of profiling the - whole system, include the kernel, kernel modules, libraries, - and applications. - - If unsure, say N. - -endmenu -
arch/sparc/oprofile/Kconfig deleted +0 -17
@@ -1,17 +0,0 @@ -config PROFILING - bool "Profiling support (EXPERIMENTAL)" - help - Say Y here to enable the extended profiling support mechanisms used - by profilers such as OProfile. - - -config OPROFILE - tristate "OProfile system profiling (EXPERIMENTAL)" - depends on PROFILING - help - OProfile is a profiling system capable of profiling the - whole system, include the kernel, kernel modules, libraries, - and applications. - - If unsure, say N. -
arch/sparc64/oprofile/Kconfig deleted +0 -17
@@ -1,17 +0,0 @@ -config PROFILING - bool "Profiling support (EXPERIMENTAL)" - help - Say Y here to enable the extended profiling support mechanisms used - by profilers such as OProfile. - - -config OPROFILE - tristate "OProfile system profiling (EXPERIMENTAL)" - depends on PROFILING - help - OProfile is a profiling system capable of profiling the - whole system, include the kernel, kernel modules, libraries, - and applications. - - If unsure, say N. -
arch/x86_64/oprofile/Kconfig deleted +0 -17
@@ -1,17 +0,0 @@ -config PROFILING - bool "Profiling support (EXPERIMENTAL)" - help - Say Y here to enable the extended profiling support mechanisms used - by profilers such as OProfile. - - -config OPROFILE - tristate "OProfile system profiling (EXPERIMENTAL)" - depends on PROFILING - help - OProfile is a profiling system capable of profiling the - whole system, include the kernel, kernel modules, libraries, - and applications. - - If unsure, say N. -
kernel/Kconfig.instrumentation new file +40 -0
@@ -0,0 +1,40 @@ +menuconfig INSTRUMENTATION + bool "Instrumentation Support" + default y + ---help--- + Say Y here to get to see options related to performance measurement, + debugging, and testing. This option alone does not add any kernel code. + + If you say N, all options in this submenu will be skipped and disabled. + +if INSTRUMENTATION + +config PROFILING + bool "Profiling support (EXPERIMENTAL)" + help + Say Y here to enable the extended profiling support mechanisms used + by profilers such as OProfile. + +config OPROFILE + tristate "OProfile system profiling (EXPERIMENTAL)" + depends on PROFILING + depends on ALPHA || ARM || BLACKFIN || X86_32 || IA64 || M32R || MIPS || PARISC || PPC || S390 || SUPERH || SPARC || X86_64 + help + OProfile is a profiling system capable of profiling the + whole system, include the kernel, kernel modules, libraries, + and applications. + + If unsure, say N. + +config KPROBES + bool "Kprobes" + depends on KALLSYMS && MODULES + depends on X86_32 || IA64 || PPC || S390 || SPARC64 || X86_64 || AVR32 + help + Kprobes allows you to trap at almost any kernel address and + execute a callback function. register_kprobe() establishes + a probepoint and specifies the callback. Kprobes is useful + for kernel debugging, non-intrusive instrumentation and testing. + If in doubt, say "N". + +endif # INSTRUMENTATION
arch/i386/Kconfig +1 -24
@@ -1251,30 +1251,7 @@ source "drivers/Kconfig" source "fs/Kconfig" -menuconfig INSTRUMENTATION - bool "Instrumentation Support" - default y - ---help--- - Say Y here to get to see options related to performance measurement, - debugging, and testing. This option alone does not add any kernel code. - - If you say N, all options in this submenu will be skipped and disabled. - -if INSTRUMENTATION - -source "arch/i386/oprofile/Kconfig" - -config KPROBES - bool "Kprobes" - depends on KALLSYMS && MODULES - help - Kprobes allows you to trap at almost any kernel address and - execute a callback function. register_kprobe() establishes - a probepoint and specifies the callback. Kprobes is useful - for kernel debugging, non-intrusive instrumentation and testing. - If in doubt, say "N". - -endif # INSTRUMENTATION +source "kernel/Kconfig.instrumentation" source "arch/i386/Kconfig.debug"
arch/alpha/Kconfig +1 -1
@@ -654,7 +654,7 @@ source "drivers/Kconfig" source "fs/Kconfig" -source "arch/alpha/oprofile/Kconfig" +source "kernel/Kconfig.instrumentation" source "arch/alpha/Kconfig.debug"
arch/arm/Kconfig +1 -1
@@ -1061,7 +1061,7 @@ endmenu source "fs/Kconfig" -source "arch/arm/oprofile/Kconfig" +source "kernel/Kconfig.instrumentation" source "arch/arm/Kconfig.debug"
arch/blackfin/Kconfig +1 -1
@@ -914,7 +914,7 @@ source "drivers/Kconfig" source "fs/Kconfig" -source "arch/blackfin/oprofile/Kconfig" +source "kernel/Kconfig.instrumentation" menu "Kernel hacking"
arch/cris/Kconfig +2 -0
@@ -196,6 +196,8 @@ source "sound/Kconfig" source "drivers/usb/Kconfig" +source "kernel/Kconfig.instrumentation" + source "arch/cris/Kconfig.debug" source "security/Kconfig"
arch/frv/Kconfig +2 -0
@@ -375,6 +375,8 @@ source "drivers/Kconfig" source "fs/Kconfig" +source "kernel/Kconfig.instrumentation" + source "arch/frv/Kconfig.debug" source "security/Kconfig"
arch/h8300/Kconfig +2 -0
@@ -223,6 +223,8 @@ endmenu source "fs/Kconfig" +source "kernel/Kconfig.instrumentation" + source "arch/h8300/Kconfig.debug" source "security/Kconfig"
arch/ia64/Kconfig +1 -14
@@ -579,20 +579,7 @@ config IRQ_PER_CPU source "arch/ia64/hp/sim/Kconfig" -menu "Instrumentation Support" - -source "arch/ia64/oprofile/Kconfig" - -config KPROBES - bool "Kprobes" - depends on KALLSYMS && MODULES - help - Kprobes allows you to trap at almost any kernel address and - execute a callback function. register_kprobe() establishes - a probepoint and specifies the callback. Kprobes is useful - for kernel debugging, non-intrusive instrumentation and testing. - If in doubt, say "N". -endmenu +source "kernel/Kconfig.instrumentation" source "arch/ia64/Kconfig.debug"
arch/m32r/Kconfig +1 -1
@@ -426,7 +426,7 @@ source "drivers/Kconfig" source "fs/Kconfig" -source "arch/m32r/oprofile/Kconfig" +source "kernel/Kconfig.instrumentation" source "arch/m32r/Kconfig.debug"
arch/m68k/Kconfig +2 -0
@@ -683,6 +683,8 @@ endmenu source "fs/Kconfig" +source "kernel/Kconfig.instrumentation" + source "arch/m68k/Kconfig.debug" source "security/Kconfig"
arch/m68knommu/Kconfig +2 -0
@@ -696,6 +696,8 @@ source "drivers/Kconfig" source "fs/Kconfig" +source "kernel/Kconfig.instrumentation" + source "arch/m68knommu/Kconfig.debug" source "security/Kconfig"
arch/mips/Kconfig +1 -1
@@ -1961,7 +1961,7 @@ source "drivers/Kconfig" source "fs/Kconfig" -source "arch/mips/oprofile/Kconfig" +source "kernel/Kconfig.instrumentation" source "arch/mips/Kconfig.debug"
arch/parisc/Kconfig +1 -1
@@ -267,7 +267,7 @@ source "drivers/Kconfig" source "fs/Kconfig" -source "arch/parisc/oprofile/Kconfig" +source "kernel/Kconfig.instrumentation" source "arch/parisc/Kconfig.debug"
arch/powerpc/Kconfig +1 -14
@@ -638,20 +638,7 @@ source "arch/powerpc/sysdev/qe_lib/Kconf source "lib/Kconfig" -menu "Instrumentation Support" - -source "arch/powerpc/oprofile/Kconfig" - -config KPROBES - bool "Kprobes" - depends on !BOOKE && !4xx && KALLSYMS && MODULES - help - Kprobes allows you to trap at almost any kernel address and - execute a callback function. register_kprobe() establishes - a probepoint and specifies the callback. Kprobes is useful - for kernel debugging, non-intrusive instrumentation and testing. - If in doubt, say "N". -endmenu +source "kernel/Kconfig.instrumentation" source "arch/powerpc/Kconfig.debug"
arch/ppc/Kconfig +1 -1
@@ -1307,7 +1307,7 @@ endmenu source "lib/Kconfig" -source "arch/powerpc/oprofile/Kconfig" +source "kernel/Kconfig.instrumentation" source "arch/ppc/Kconfig.debug"
arch/s390/Kconfig +1 -15
@@ -529,21 +529,7 @@ source "drivers/Kconfig" source "fs/Kconfig" -menu "Instrumentation Support" - -source "arch/s390/oprofile/Kconfig" - -config KPROBES - bool "Kprobes (EXPERIMENTAL)" - depends on EXPERIMENTAL && MODULES - help - Kprobes allows you to trap at almost any kernel address and - execute a callback function. register_kprobe() establishes - a probepoint and specifies the callback. Kprobes is useful - for kernel debugging, non-intrusive instrumentation and testing. - If in doubt, say "N". - -endmenu +source "kernel/Kconfig.instrumentation" source "arch/s390/Kconfig.debug"
arch/sh/Kconfig +1 -1
@@ -749,7 +749,7 @@ source "drivers/Kconfig" source "fs/Kconfig" -source "arch/sh/oprofile/Kconfig" +source "kernel/Kconfig.instrumentation" source "arch/sh/Kconfig.debug"
arch/sh64/Kconfig +1 -1
@@ -285,7 +285,7 @@ source "drivers/Kconfig" source "fs/Kconfig" -source "arch/sh64/oprofile/Kconfig" +source "kernel/Kconfig.instrumentation" source "arch/sh64/Kconfig.debug"
arch/sparc/Kconfig +1 -5
@@ -320,11 +320,7 @@ endmenu source "fs/Kconfig" -menu "Instrumentation Support" - -source "arch/sparc/oprofile/Kconfig" - -endmenu +source "kernel/Kconfig.instrumentation" source "arch/sparc/Kconfig.debug"
arch/sparc64/Kconfig +1 -14
@@ -460,20 +460,7 @@ source "drivers/fc4/Kconfig" source "fs/Kconfig" -menu "Instrumentation Support" - -source "arch/sparc64/oprofile/Kconfig" - -config KPROBES - bool "Kprobes (EXPERIMENTAL)" - depends on KALLSYMS && EXPERIMENTAL && MODULES - help - Kprobes allows you to trap at almost any kernel address and - execute a callback function. register_kprobe() establishes - a probepoint and specifies the callback. Kprobes is useful - for kernel debugging, non-intrusive instrumentation and testing. - If in doubt, say "N". -endmenu +source "kernel/Kconfig.instrumentation" source "arch/sparc64/Kconfig.debug"
arch/um/Kconfig +2 -0
@@ -289,4 +289,6 @@ config INPUT bool default n +source "kernel/Kconfig.instrumentation" + source "arch/um/Kconfig.debug"
arch/v850/Kconfig +2 -0
@@ -331,6 +331,8 @@ source "sound/Kconfig" source "drivers/usb/Kconfig" +source "kernel/Kconfig.instrumentation" + source "arch/v850/Kconfig.debug" source "security/Kconfig"
arch/x86_64/Kconfig +1 -14
@@ -833,20 +833,7 @@ source "drivers/firmware/Kconfig" source fs/Kconfig -menu "Instrumentation Support" - -source "arch/x86_64/oprofile/Kconfig" - -config KPROBES - bool "Kprobes" - depends on KALLSYMS && MODULES - help - Kprobes allows you to trap at almost any kernel address and - execute a callback function. register_kprobe() establishes - a probepoint and specifies the callback. Kprobes is useful - for kernel debugging, non-intrusive instrumentation and testing. - If in doubt, say "N". -endmenu +source "kernel/Kconfig.instrumentation" source "arch/x86_64/Kconfig.debug"
arch/xtensa/Kconfig +2 -0
@@ -251,6 +251,8 @@ config EMBEDDED_RAMDISK_IMAGE provide one yourself. endmenu +source "kernel/Kconfig.instrumentation" + source "arch/xtensa/Kconfig.debug" source "security/Kconfig"
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
PATCH 4/7 Linux Kernel Markers - Architecture Independent Code
In reply to Mathieu DesnoyersThe 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.
Changelog:
- markers_mutex now nests inside module_mutex rather than the opposite.
- Iteration on modules is now done in module.c.
- module_mutex is not exported anymore.
- Don't declare a __markers_strings section.
- Simplified: do not use immediate values, just a simple variable read. (removed dependency on immediate values).
- Removed the args field in the marker structure : it was not used.
---
include/asm-generic/vmlinux.lds.h | 7 include/linux/marker.h | 142 ++++++++ include/linux/module.h | 18 + kernel/marker.c | 607 ++++++++++++++++++++++++++++++++++++++ kernel/module.c | 64 +++- 5 files changed, 836 insertions(+), 2 deletions(-)
include/asm-generic/vmlinux.lds.h +6 -1
@@ -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)); \
@@ -20,6 +24,7 @@ VMLINUX_SYMBOL(__start_rodata) = .; \ *(.rodata) *(.rodata.*) \ *(__vermagic)/* Kernel version magic */ \ + *(__markers_strings)/* Markers: strings */ \ } \ \ .rodata1 : AT(ADDR(.rodata1) - LOAD_OFFSET) { \
include/linux/marker.h new file +142 -0
142 lines not on this page · raw message
include/linux/module.h +18 -0
@@ -15,6 +15,7 @@#include <linux/stringify.h> #include <linux/kobject.h> #include <linux/moduleparam.h> +#include <linux/marker.h> #include <asm/local.h> #include <asm/module.h>
@@ -370,6 +371,10 @@ struct module/* The command line arguments (may be mangled). People like keeping pointers to this stuff */ char *args; +#ifdef CONFIG_MARKERS +struct __mark_marker *markers; +unsigned int num_markers; +#endif };#ifndef MODULE_ARCH_INIT #define MODULE_ARCH_INIT {}
@@ -473,6 +478,9 @@ int unregister_module_notifier(struct noextern void print_modules (void ); +extern void module_update_markers (struct module *probe_module,int *refcount); +extern int module_get_iter_markers (struct marker_iter *iter); +#else /* !CONFIG_MODULES... */ #define EXPORT_SYMBOL (sym)#define EXPORT_SYMBOL_GPL (sym)
@@ -572,6 +580,16 @@ static inline void print_modules(void) { } +static inline void module_update_markers (struct module *probe_module, +int *refcount) +{ +} + +static inline int module_get_iter_markers (struct marker_iter *iter) +{ +return 0 ; +} +#endif /* CONFIG_MODULES */ struct device_driver ;
kernel/module.c +63 -1
91 lines not on this page · raw message
kernel/marker.c new file +607 -0
607 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
Re: [patch 4/7] Linux Kernel Markers - Architecture Independent Code
include/linux/marker.h line 40
Quoted 8 lines · Mathieu Desnoyers
include/linux/marker.h new file +8
-0+struct __mark_marker { +const char *name;/* Marker name */ +const char *format;/* Marker format string, describing the +* variable argument list. +*/ +char state;/* Marker state. */ +marker_probe_func *call;/* Probe handler function pointer */ +void *pdata;/* Private probe data */
This is normally called private in the kernel, and keeping this consistant would be nice.
Quoted 1 line
+} __attribute__((aligned(8)));
Why do we care about the alignment here?
include/linux/marker.h line 105
Quoted 3 lines
include/linux/marker.h new file +3
-0+/* To be used for string format validity checking with gcc */ +static inline void __attribute__ ((format (printf,1 ,2 ))) +__mark_check_format (const char *fmt, ...) { }
Please put each of the curly braces on a line of it's own, so it's clear this is an empty inline from the 1000 feet few, as it first looks like a prototype. Also aren't __attributes__ normally afer the function identifier, ala:
static inline void __mark_check_format(const char *fmt, ...)
__attribute__ ((format (printf, 1, 2)))
{
}
or is this after notation only for prototypes but not actual implementations? (yeah, gnu C extensions sometimes have syntax that odd)
Quoted 4 lines
kernel/module.c +4
-0+#ifdef CONFIG_MARKERS +void module_update_markers (struct module *probe_module,int *refcount) +{ +struct module *mod;
kernel/module.c EXPORT_SYMBOL(module_remove_driver); · line 2674
Quoted 10 lines
kernel/module.c +10
-0+ +mutex_lock (&module_mutex); +list_for_each_entry (mod, &modules, list) +if (!mod->taints) +marker_update_probe_range (mod->markers, + mod->markers + mod->num_markers, + probe_module, refcount); +mutex_unlock (&module_mutex); +} +EXPORT_SYMBOL_GPL (module_update_markers);
Why is this exported? The markers code is always built into the kernel, isn't it?
Quoted 1 line
+EXPORT_SYMBOL_GPL(module_get_iter_markers);
Same here.
kernel/marker.c line 106
Quoted 6 lines
kernel/marker.c new file +6
-0+/* +* Add the marker to the marker hash table. Must be called with markers_mutex +* held. +*/ +static int add_marker (const char *name, +const char *format,marker_probe_func *probe,void *pdata)
static int add_marker(const char *name, const char *format,
marker_probe_func *probe, void *private)
kernel/marker.c line 267
Quoted 5 lines
kernel/marker.c new file +5
-0+void marker_update_probe_range ( +struct __mark_marker *begin, +struct __mark_marker *end, +struct module *probe_module, +int *refcount)
void marker_update_probe_range(struct __mark_marker *begin,
struct __mark_marker *end, struct module *probe_module, int *refcount)
Quoted 1 line
+EXPORT_SYMBOL_GPL(marker_update_probe_range);
What is this one exported for?
kernel/marker.c line 296
Quoted 7 lines
kernel/marker.c new file +7
-0+/* +* Update probes, removing the faulty probes. +* Issues a synchronize_sched() when no reference to the module passed +* as parameter is found in the probes so the probe module can be +* safely unloaded from now on. +*/ +static inline void marker_update_probes (struct module *probe_module)
no need to mark this inline, the compiler takes care of that for you if nessecary.
kernel/marker.c line 542
Quoted 3 lines
kernel/marker.c new file +3
-0+int marker_get_iter_range (struct __mark_marker **marker, +struct __mark_marker *begin, +struct __mark_marker *end)
int marker_get_iter_range(struct __mark_marker **marker,
struct __mark_marker *begin, struct __mark_marker *end)
kernel/marker.c line 555
Quoted 12 lines
kernel/marker.c new file +12
-0+int found =0 ; + +if (!*marker && begin != end) { + found =1 ; + *marker = begin; + }else if (*marker >= begin && *marker < end) { + found =1 ; +/* +* *marker is known to be a valid marker from now on. +*/ + } +return found;
if (!*marker && begin != end) {
*marker = begin;
return 1;
}
if (*marker >= begin && *marker < end)
return 1;
return 0;?
There seem to be a lot of exports and some functions that don't seem to be used by the obvious marker use-cases like your example, blktrace or sputrace. Care to explain why we'd really want them or better cut them out for this first submission?
Re: [patch 4/7] Linux Kernel Markers - Architecture Independent Code
Quoted 4 lines · Christoph Hellwig
static inline void
__mark_check_format(const char *fmt, ...)__attribute__ ((format (printf, 1, 2))){
}
the header file compiler-gcc.h defines the shorter macro "__printf". is it worth encouraging its use, or does it matter?
rday
Signature · 7 lines
======================================================================== Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://crashcourse.ca ========================================================================
Re: [patch 4/7] Linux Kernel Markers - Architecture Independent Code
Quoted 9 lines · Robert P. J. Day
Quoted 4 lines · Christoph Hellwig
static inline void
__mark_check_format(const char *fmt, ...)__attribute__ ((format (printf, 1, 2))){
}the header file
compiler-gcc.hdefines the shorter macro "__printf". is it worth encouraging its use, or does it matter?
Yes, that's even better.
Re: [patch 4/7] Linux Kernel Markers - Architecture Independent Code
Quoted 8 lines · * Christoph Hellwig ([email protected]) wrote:
Quoted 7 lines · Robert P. J. Day
Quoted 4 lines · Christoph Hellwig
static inline void
__mark_check_format(const char *fmt, ...)__attribute__ ((format (printf, 1, 2))){
}
Quoted 4 lines
Quoted 2 lines
the header file
compiler-gcc.hdefines the shorter macro "__printf". is it worth encouraging its use, or does it matter?Yes, that's even better.
Ok, fixing.
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
Re: [patch 4/7] Linux Kernel Markers - Architecture Independent Code
In reply to Christoph HellwigQuoted 13 lines · * Christoph Hellwig ([email protected]) wrote:
include/linux/marker.h line 40
Quoted 8 lines · Mathieu Desnoyers
include/linux/marker.h new file +8
-0+struct __mark_marker { +const char *name;/* Marker name */ +const char *format;/* Marker format string, describing the +* variable argument list. +*/ +char state;/* Marker state. */ +marker_probe_func *call;/* Probe handler function pointer */ +void *pdata;/* Private probe data */ This is normally called private in the kernel, and keeping this consistant would be nice.
Ok, fixing.
Quoted 4 lines
Quoted 1 line
+} __attribute__((aligned(8)));
Why do we care about the alignment here?
Because we want to be really-really-really sure GCC won't align this structure on 32 bytes. Here is the problematic scenario:
Developer A adds a few fields to struct __mark_marker, making it 32 bytes in size.include/asm-generic/vmlinux.lds.h specifies
. = ALIGN(8); \
VMLINUX_SYMBOL(__start___markers) = .; \
*(__markers) \
VMLINUX_SYMBOL(__stop___markers) = .;Therefore, the __start___markers "begin" iterator will always be 8 bytes aligned, but if GCC decides to align the structures on 32 bytes, we can end up with padding at the beginning of our iterator.
Therefore, to make sure there won't be any unforeseen side-effect of any changes to this structure, I specify the structure alignment there.
Quoted 9 lines
include/linux/marker.h line 105
Quoted 3 lines
include/linux/marker.h new file +3
-0+/* To be used for string format validity checking with gcc */ +static inline void __attribute__ ((format (printf,1 ,2 ))) +__mark_check_format (const char *fmt, ...) { }Please put each of the curly braces on a line of it's own, so it's clear this is an empty inline from the 1000 feet few, as it first looks like a prototype. Also aren't
__attributes__normally afer the function identifier, ala:
Ok, fixing __mark_empty_function too for the braces.
Quoted 8 lines
static inline void
__mark_check_format(const char *fmt, ...)__attribute__ ((format (printf, 1, 2))){
}or is this after notation only for prototypes but not actual implementations? (yeah, gnu C extensions sometimes have syntax that odd)
Build error
In file included from include/linux/module.h:19,
from include/linux/crypto.h:22,
from arch/i386/kernel/asm-offsets.c:8:include/linux/marker.h:106: error: expected ',' or ';' before '{' token distcc[3903] ERROR: compile arch/i386/kernel/asm-offsets.c on dijkstra failed
gcc doesn't like it if I put the attribute after the function in the implementation. Should I leave it before or separate the prototype from the implementation ?
Quoted 19 lines
Quoted 5 lines
kernel/module.c +4
-0+#ifdef CONFIG_MARKERS +void module_update_markers (struct module *probe_module,int *refcount) +{ +struct module *mod;kernel/module.c EXPORT_SYMBOL(module_remove_driver); · line 2674
Quoted 10 lines
kernel/module.c +10
-0+ +mutex_lock (&module_mutex); +list_for_each_entry (mod, &modules, list) +if (!mod->taints) +marker_update_probe_range (mod->markers, + mod->markers + mod->num_markers, + probe_module, refcount); +mutex_unlock (&module_mutex); +} +EXPORT_SYMBOL_GPL (module_update_markers);Why is this exported? The markers code is always built into the kernel, isn't it?
Quoted 3 lines
Quoted 1 line
+EXPORT_SYMBOL_GPL(module_get_iter_markers);
Same here.
Yep, good point. Fixing.
Quoted 10 lines
kernel/marker.c line 267
Quoted 5 lines
kernel/marker.c new file +5
-0+void marker_update_probe_range ( +struct __mark_marker *begin, +struct __mark_marker *end, +struct module *probe_module, +int *refcount)void marker_update_probe_range(struct
__mark_marker*begin,
struct__mark_marker*end, struct module*probe_module, int *refcount)
ok
Quoted 4 lines
Quoted 1 line
+EXPORT_SYMBOL_GPL(marker_update_probe_range);
What is this one exported for?
Only used by module.c, should not be exported.
Quoted 11 lines
kernel/marker.c line 296
Quoted 7 lines
kernel/marker.c new file +7
-0+/* +* Update probes, removing the faulty probes. +* Issues a synchronize_sched() when no reference to the module passed +* as parameter is found in the probes so the probe module can be +* safely unloaded from now on. +*/ +static inline void marker_update_probes (struct module *probe_module)no need to mark this inline, the compiler takes care of that for you if nessecary.
I'll change all static inlines into static in kernel/marker.c since, as you point out, gcc knows its job. I originally used all "static inline" following a comment from Andrew.
Quoted 22 lines
kernel/marker.c line 555
Quoted 12 lines
kernel/marker.c new file +12
-0+int found =0 ; + +if (!*marker && begin != end) { + found =1 ; + *marker = begin; + }else if (*marker >= begin && *marker < end) { + found =1 ; +/* +* *marker is known to be a valid marker from now on. +*/ + } +return found;if (!*marker && begin != end) { *marker = begin; return 1; } if (*marker >= begin && *marker < end) return 1; return 0;
Quoted 2 lines
?
Clearly, this simple layout did not come out from the evolution of the code. Will fix.
Quoted 5 lines
There seem to be a lot of exports and some functions that don't seem to be used by the obvious marker use-cases like your example, blktrace or sputrace. Care to explain why we'd really want them or better cut them out for this first submission?
If you are referring to the exports you just told about in this email, I'll remove them, they are not needed. As for the "marker_get_iter" and friends, they are used to list the markers (I provide a /proc interface to list the markers in the subsequent modules and also use it to dump the marker list in a trace channel at trace start so I can later understand the event data by using the format strings as type identifiers).
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
Re: [patch 4/7] Linux Kernel Markers - Architecture Independent Code
Quoted 3 lines · Mathieu Desnoyers
gcc doesn't like it if I put the attribute after the function in the implementation. Should I leave it before or separate the prototype from the implementation ?
Just keep it where it was.
Quoted 5 lines
Quoted 4 lines
There seem to be a lot of exports and some functions that don't seem to be used by the obvious marker use-cases like your example, blktrace or sputrace. Care to explain why we'd really want them or better cut them out for this first submission?
Quoted 7 lines
If you are referring to the exports you just told about in this email, I'll remove them, they are not needed. As for the "
marker_get_iter" and friends, they are used to list the markers (I provide a /proc interface to list the markers in the subsequent modules and also use it to dump the marker list in a trace channel at trace start so I can later understand the event data by using the format strings as type identifiers).
Sounds conceptually fine, but can we introduce this together with the actualy users?
Re: [patch 4/7] Linux Kernel Markers - Architecture Independent Code
Quoted 20 lines · * Christoph Hellwig ([email protected]) wrote:
Quoted 3 lines · Mathieu Desnoyers
gcc doesn't like it if I put the attribute after the function in the implementation. Should I leave it before or separate the prototype from the implementation ?
Just keep it where it was.
Quoted 5 lines
Quoted 4 lines
There seem to be a lot of exports and some functions that don't seem to be used by the obvious marker use-cases like your example, blktrace or sputrace. Care to explain why we'd really want them or better cut them out for this first submission?
Quoted 7 lines
If you are referring to the exports you just told about in this email, I'll remove them, they are not needed. As for the "
marker_get_iter" and friends, they are used to list the markers (I provide a /proc interface to list the markers in the subsequent modules and also use it to dump the marker list in a trace channel at trace start so I can later understand the event data by using the format strings as type identifiers).
Quoted 2 lines
Sounds conceptually fine, but can we introduce this together with the actualy users?
Sure, I'll move that down in my patch queue.
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
PATCH 5/7 Linux Kernel Markers - Use instrumentation kconfig menu
In reply to Mathieu DesnoyersWith 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. (see immediate values)
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.
--- kernel/Kconfig.instrumentation | 13 +++++++++++-- kernel/Makefile | 1 + 2 files changed, 12 insertions(+), 2 deletions(-)
kernel/Kconfig.instrumentation +11 -2
@@ -3,9 +3,12 @@ menuconfig INSTRUMENTATION default y ---help--- Say Y here to get to see options related to performance measurement, - debugging, and testing. This option alone does not add any kernel code. + system-wide debugging, and testing. This option alone does not add any + kernel code. - If you say N, all options in this submenu will be skipped and disabled. + If you say N, all options in this submenu will be skipped and + disabled. If you're trying to debug the kernel itself, go see the + Kernel Hacking menu. if INSTRUMENTATION
@@ -37,4 +40,10 @@ config KPROBES for kernel debugging, non-intrusive instrumentation and testing. If in doubt, say "N". +config MARKERS + bool "Activate markers" + help + Place an empty function call at each marker site. Can be + dynamically changed for a probe function. + endif # INSTRUMENTATION
kernel/Makefile +1 -0
@@ -61,6 +61,7 @@ obj-$(CONFIG_SYSCTL) += utsname_sysctl.o obj-$(CONFIG_TASK_DELAY_ACCT) += delayacct.o obj-$(CONFIG_TASKSTATS) += taskstats.o tsacct.o obj-$(CONFIG_RESOURCE_COUNTERS) += res_counter.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
Re: [patch 5/7] Linux Kernel Markers - Use instrumentation kconfig menu
Subject and description sounds rather odd for just wiring up Kconfig and Makefile. I'd suggest merging this into the previous patch. In fact given how small markers are it might make sense to put the documentation into it aswell, it's probably still a lot below 400k.
Re: [patch 5/7] Linux Kernel Markers - Use instrumentation kconfig menu
Quoted 5 lines · * Christoph Hellwig ([email protected]) wrote:
Subject and description sounds rather odd for just wiring up
KconfigandMakefile. I'd suggest merging this into the previous patch. In fact given how small markers are it might make sense to put the documentation into it aswell, it's probably still a lot below 400k.
Good point, let's do it.
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
PATCH 6/7 Linux Kernel Markers - Documentation
In reply to Mathieu DesnoyersHere is some documentation explaining what is/how to use the Linux Kernel Markers.
---
Documentation/markers/markers.txt | 81 +++++++++++++++++++++++ Documentation/markers/src/Makefile | 7 ++ Documentation/markers/src/marker-example.c | 55 ++++++++++++++++ Documentation/markers/src/probe-example.c | 98 +++++++++++++++++++++++++++++ 4 files changed, 241 insertions(+)
Documentation/markers/markers.txt new file +81 -0
@@ -0,0 +1,81 @@ + 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 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. + + +* Usage + +In order to use the macro trace_mark, you should include linux/marker.h. + +#include <linux/marker.h> + +And, + +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 as well as regular functions. + +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)" + + +* Probe / marker example + +See the example provided in Documentation/markers/src + +Run, 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
Documentation/markers/src/Makefile new file +7 -0
@@ -0,0 +1,7 @@ +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
Documentation/markers/src/marker-example.c new file +55 -0
55 lines not on this page · raw message
Documentation/markers/src/probe-example.c new file +98 -0
98 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
Re: [patch 6/7] Linux Kernel Markers - Documentation
Quoted 2 lines · Mathieu Desnoyers
Here is some documentation explaining what is/how to use the Linux Kernel Markers.
As mentioned in the tracing infrastructure thread I don't think putting code into Documentation is a good idea. Either of you really should start a sample/ toplevel directory for this kind of stuff including a Kconfig menu etc to be able to build these samples as part of an allmodconfig.
Re: [patch 6/7] Linux Kernel Markers - Documentation
Quoted 9 lines · On Mon, 24 Sep 2007 18:50:44 +0100 Christoph Hellwig wrote:
Quoted 2 lines · Mathieu Desnoyers
Here is some documentation explaining what is/how to use the Linux Kernel Markers.
As mentioned in the tracing infrastructure thread I don't think putting code into Documentation is a good idea. Either of you really should start a sample/ toplevel directory for this kind of stuff including a
Kconfigmenu etc to be able to build these samples as part of an allmodconfig.
I don't have a problem with a samples/ directory except (as I have already pointed out) it means that people will end up having to look in 2 places for the information that they need, i.e., both in samples/ and in Documentation/. So I really don't see a big need to split the samples and docs.
What's wrong with building sample code in the Documentation/ directory?
---
~Randy
Phaedrus says that Quality is about caring.
Re: [patch 6/7] Linux Kernel Markers - Documentation
Quoted 7 lines · Randy Dunlap
I don't have a problem with a
samples/directory except (as I have already pointed out) it means that people will end up having to look in 2 places for the information that they need, i.e., both insamples/and inDocumentation/. So I really don't see a big need to split the samples and docs.What's wrong with building sample code in the
Documentation/directory?
It's not really documentation, it's code :) If you want to build documentation from the samples use kerneldoc or similar to extrace the comments. Having Documentation/ purely for things not affecting the build make things a whole lot clearer, but if you absolutely insist on it we can put it under Documentation/ as long as it's fully integrated into kbuild and will be built as part of allmodconfig, unlike the current two patches showing code there.
Re: [patch 6/7] Linux Kernel Markers - Documentation
Quoted 9 lines · On Mon, 24 Sep 2007 19:00:41 +0100 Christoph Hellwig wrote:
Quoted 7 lines · Randy Dunlap
I don't have a problem with a
samples/directory except (as I have already pointed out) it means that people will end up having to look in 2 places for the information that they need, i.e., both insamples/and inDocumentation/. So I really don't see a big need to split the samples and docs.What's wrong with building sample code in the
Documentation/directory?
Quoted 8 lines
It's not really documentation, it's code :) If you want to build documentation from the samples use kerneldoc or similar to extrace the comments. Having
Documentation/purely for things not affecting the build make things a whole lot clearer, but if you absolutely insist on it we can put it underDocumentation/as long as it's fully integrated into kbuild and will be built as part of allmodconfig, unlike the current two patches showing code there.
-
Yes, it has to be integrated into the build system, no doubt.
We really need to give Mathieu and David Wilder an answer so that they can make progress (and I'm willing to help with this).
To do this, here's my test question:
How much of David's "trace code and documentation" patch can be put into a samples/ directory?
Documentation/trace/src/Makefile | 7 + Documentation/trace/src/README | 18 + Documentation/trace/src/fork_trace.c | 119 +++++++ Documentation/trace/trace.txt | 164 ++++++++++ include/linux/trace.h | 99 ++++++ lib/Kconfig | 9 + lib/Makefile | 2 + lib/trace.c | 563 +++++++++++++++++++++++++++ +++++++ 8 files changed, 981 insertions(+), 0 deletions(-)
All of the trace/src/ subdirectory?
---
~Randy
Phaedrus says that Quality is about caring.
Re: [patch 6/7] Linux Kernel Markers - Documentation
Quoted 12 lines · Randy Dunlap
Documentation/trace/src/Makefile | 7 + Documentation/trace/src/README | 18 + Documentation/trace/src/fork_trace.c | 119 +++++++ Documentation/trace/trace.txt | 164 ++++++++++ include/linux/trace.h | 99 ++++++ lib/Kconfig | 9 + lib/Makefile | 2 + lib/trace.c | 563 +++++++++++++++++++++++++++ +++++++ 8 files changed, 981 insertions(+), 0 deletions(-)
Quoted 1 line
All of the trace/src/ subdirectory?
Yes, but only as a single file. We don't really want READMES in source directories. Instead these 18 lines would do a perfect comment on the top of the file.
Re: [patch 6/7] Linux Kernel Markers - Documentation
Quoted 13 lines · Christoph Hellwig
Quoted 12 lines · Randy Dunlap
Documentation/trace/src/Makefile | 7 + Documentation/trace/src/README | 18 + Documentation/trace/src/fork_trace.c | 119 +++++++ Documentation/trace/trace.txt | 164 ++++++++++ include/linux/trace.h | 99 ++++++ lib/Kconfig | 9 + lib/Makefile | 2 + lib/trace.c | 563 +++++++++++++++++++++++++++ +++++++ 8 files changed, 981 insertions(+), 0 deletions(-)
Quoted 5 lines
Quoted 1 line
All of the trace/src/ subdirectory?
Yes, but only as a single file. We don't really want READMES in source directories. Instead these 18 lines would do a perfect comment on the top of the file.
That might be OK for this case, but sometimes it makes sense to have README etc. about how to use the software. So you would want this in the Documentation/ tree? That makes it harder on users.
Signature · 2 lines
~Randy Phaedrus says that Quality is about caring.
Re: [patch 6/7] Linux Kernel Markers - Documentation
Quoted 3 lines · Randy Dunlap
That might be OK for this case, but sometimes it makes sense to have README etc. about how to use the software. So you would want this in the
Documentation/tree? That makes it harder on users.
If it's so complex that we can't describe it in a few dozens lines it shouldn't be anywhere but the place it belongs and better have a real use and not just be a sample. And in the trace case I must admit that I'd prefer a real use like some simple syscall-trace over this hack anyway..
Re: [patch 6/7] Linux Kernel Markers - Documentation
Quoted 10 lines · Christoph Hellwig
Quoted 3 lines · Randy Dunlap
That might be OK for this case, but sometimes it makes sense to have README etc. about how to use the software. So you would want this in the
Documentation/tree? That makes it harder on users.If it's so complex that we can't describe it in a few dozens lines it shouldn't be anywhere but the place it belongs and better have a real use and not just be a sample. And in the trace case I must admit that I'd prefer a real use like some simple syscall-trace over this hack anyway..
I think that samples are perfectly fine for documentation and that the trace example is a good example. I think that most people who need something like that would need to customize it for their specific needs anyway.
We don't seem to be making progress...
Signature · 2 lines
~Randy Phaedrus says that Quality is about caring.
Re: [patch 6/7] Linux Kernel Markers - Documentation
Quoted 6 lines · Randy Dunlap
I think that samples are perfectly fine for documentation and that the trace example is a good example. I think that most people who need something like that would need to customize it for their specific needs anyway.
We don't seem to be making progress...
Time to bring in a Tie-Breaker :)
Re: [patch 6/7] Linux Kernel Markers - Documentation
Quoted 9 lines · Christoph Hellwig
Quoted 6 lines · Randy Dunlap
I think that samples are perfectly fine for documentation and that the trace example is a good example. I think that most people who need something like that would need to customize it for their specific needs anyway.
We don't seem to be making progress...
Time to bring in a Tie-Breaker :)
Yes. Is anyone else interested? :(
Signature · 2 lines
~Randy Phaedrus says that Quality is about caring.
Re: [patch 6/7] Linux Kernel Markers - Documentation
Quoted 7 lines · On Mon, 24 Sep 2007 11:56:35 -0700 Randy Dunlap wrote:
Quoted 6 lines · Christoph Hellwig
Quoted 5 lines · Randy Dunlap
I think that samples are perfectly fine for documentation and that the trace example is a good example. I think that most people who need something like that would need to customize it for their specific needs anyway.
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
We don't seem to be making progress...
Time to bring in a Tie-Breaker :)
Yes. Is anyone else interested? :(
I guess that's everyone (except those who are sleeping).
Let's not hold up progress. Just use samples/ for code.
---
~Randy
Phaedrus says that Quality is about caring.
Re: [patch 6/7] Linux Kernel Markers - Documentation
Quoted 11 lines · * Randy Dunlap ([email protected]) wrote:
Quoted 9 lines · On Mon, 24 Sep 2007 11:56:35 -0700 Randy Dunlap wrote:
Quoted 8 lines · Christoph Hellwig
Quoted 6 lines · Randy Dunlap
I think that samples are perfectly fine for documentation and that the trace example is a good example. I think that most people who need something like that would need to customize it for their specific needs anyway.
We don't seem to be making progress...
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
Time to bring in a Tie-Breaker :)
Yes. Is anyone else interested? :(
I guess that's everyone (except those who are sleeping).
Let's not hold up progress. Just use
samples/for code.
Would you already have the
Makefilesamples/Kconfigsamples/Makefile
core code handy per chance ? (and probably Kconfig sourcing in every arch ?)
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
Re: [patch 6/7] Linux Kernel Markers - Documentation
Quoted 21 lines · On Mon, 24 Sep 2007 17:08:30 -0400 Mathieu Desnoyers wrote:
Quoted 11 lines · * Randy Dunlap ([email protected]) wrote:
Quoted 9 lines · On Mon, 24 Sep 2007 11:56:35 -0700 Randy Dunlap wrote:
Quoted 8 lines · Christoph Hellwig
Quoted 6 lines · Randy Dunlap
I think that samples are perfectly fine for documentation and that the trace example is a good example. I think that most people who need something like that would need to customize it for their specific needs anyway.
We don't seem to be making progress...
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
Time to bring in a Tie-Breaker :)
Yes. Is anyone else interested? :(
I guess that's everyone (except those who are sleeping).
Let's not hold up progress. Just use
samples/for code.
Quoted 8 lines
Would you already have the
Makefilesamples/Kconfigsamples/Makefilecore code handy per chance ? (and probably
Kconfigsourcing in every arch ?)
Yes. Here it is. I'm working on add kprobes to it, but you can go ahead with markers also.
From: Randy Dunlap <[email protected]>
Begin infrastructure for kernel code samples in the samples/ directory. Add its Kconfig and Kbuild files.
Source its Kconfig file in all arch/ Kconfigs.
--- Makefile | 10 +++++++--- arch/alpha/Kconfig | 2 ++ arch/arm/Kconfig | 2 ++ arch/avr32/Kconfig | 2 ++ arch/blackfin/Kconfig | 2 ++ 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 | 3 ++- samples/Kbuild | 2 ++ samples/Kconfig | 11 +++++++++++ 28 files changed, 70 insertions(+), 4 deletions(-)
Makefile +7 -3
@@ -436,6 +436,7 @@ drivers-y := drivers/ sound/ net-y := net/ libs-y := lib/ core-y := usr/ +samples-y := samples/ endif # KBUILD_EXTMOD ifeq ($(dot-config),1)
@@ -564,10 +565,12 @@ core-y += kernel/ mm/ fs/ ipc/ security vmlinux-dirs := $(patsubst %/,%,$(filter %/, $(init-y) $(init-m) \ $(core-y) $(core-m) $(drivers-y) $(drivers-m) \ - $(net-y) $(net-m) $(libs-y) $(libs-m))) + $(net-y) $(net-m) $(libs-y) $(libs-m)) \ + $(samples-y) $(samples-m)) + vmlinux-alldirs := $(sort $(vmlinux-dirs) $(patsubst %/,%,$(filter %/, \ - $(init-n) $(init-) \ + $(init-n) $(init-) $(samples-n) $(samples-) \ $(core-n) $(core-) $(drivers-n) $(drivers-) \ $(net-n) $(net-) $(libs-n) $(libs-))))
@@ -578,6 +581,7 @@ net-y := $(patsubst %/, %/built-in.o, $ libs-y1 := $(patsubst %/, %/lib.a, $(libs-y)) libs-y2 := $(patsubst %/, %/built-in.o, $(libs-y)) libs-y := $(libs-y1) $(libs-y2) +samples-y := $(patsubst %/, %/built-in.o, $(samples-y)) # Build vmlinux # ---------------------------------------------------------------------------
@@ -607,7 +611,7 @@ libs-y := $(libs-y1) $(libs-y2) # System.map is generated to document addresses of all kernel symbols vmlinux-init := $(head-y) $(init-y) -vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y) +vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y) $(samples-y) vmlinux-all := $(vmlinux-init) $(vmlinux-main) vmlinux-lds := arch/$(ARCH)/kernel/vmlinux.lds export KBUILD_VMLINUX_OBJS := $(vmlinux-all)
samples/Kbuild new file +2 -0
@@ -0,0 +1,2 @@ +# Makefile for Linux samples code +
samples/Kconfig new file +11 -0
@@ -0,0 +1,11 @@ +# samples/Kconfig + +menuconfig SAMPLES + bool "Sample kernel code" + help + You can build and test sample kernel code here. + +if SAMPLES + + +endif # SAMPLES
arch/alpha/Kconfig +2 -0
@@ -669,5 +669,7 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"
arch/arm/Kconfig +2 -0
@@ -1067,4 +1067,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"
arch/avr32/Kconfig +2 -0
@@ -237,4 +237,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"
arch/blackfin/Kconfig +2 -0
@@ -1012,4 +1012,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"
arch/cris/Kconfig +2 -0
@@ -202,4 +202,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"
arch/frv/Kconfig +2 -0
@@ -381,4 +381,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"
arch/h8300/Kconfig +2 -0
@@ -229,4 +229,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"
arch/i386/Kconfig +2 -0
@@ -1260,6 +1260,8 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig" #
arch/ia64/Kconfig +2 -0
@@ -594,3 +594,5 @@ source "arch/ia64/Kconfig.debug" source "security/Kconfig" source "crypto/Kconfig" + +source "samples/Kconfig"
arch/m32r/Kconfig +2 -0
@@ -434,4 +434,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"
arch/m68k/Kconfig +2 -0
@@ -689,4 +689,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"
arch/m68knommu/Kconfig +2 -0
@@ -702,4 +702,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"
arch/mips/Kconfig +2 -0
@@ -1924,4 +1924,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"
arch/parisc/Kconfig +2 -0
@@ -275,4 +275,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"
arch/powerpc/Kconfig +2 -0
@@ -662,3 +662,5 @@ config KEYS_COMPAT default y source "crypto/Kconfig" + +source "samples/Kconfig"
arch/ppc/Kconfig +2 -0
@@ -1460,3 +1460,5 @@ source "arch/ppc/Kconfig.debug" source "security/Kconfig" source "crypto/Kconfig" + +source "samples/Kconfig"
arch/s390/Kconfig +2 -0
@@ -551,4 +551,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"
arch/sh/Kconfig +2 -0
@@ -739,4 +739,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"
arch/sh64/Kconfig +2 -0
@@ -293,6 +293,8 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig" #
arch/sparc/Kconfig +2 -0
@@ -333,4 +333,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"
arch/sparc64/Kconfig +2 -0
@@ -482,4 +482,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"
arch/um/Kconfig +2 -0
@@ -320,6 +320,8 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig" source "drivers/scsi/Kconfig"
arch/v850/Kconfig +2 -0
@@ -337,6 +337,8 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig" #############################################################################
arch/x86_64/Kconfig +2 -0
@@ -805,4 +805,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"
arch/xtensa/Kconfig +2 -1
@@ -257,6 +257,7 @@ source "security/Kconfig" source "crypto/Kconfig" -source "lib/Kconfig" +source "samples/Kconfig" +source "lib/Kconfig"
Re: [patch 6/7] Linux Kernel Markers - Documentation
Quoted 29 lines · * Randy Dunlap ([email protected]) wrote:
Quoted 27 lines · On Mon, 24 Sep 2007 17:08:30 -0400 Mathieu Desnoyers wrote:
Quoted 11 lines · * Randy Dunlap ([email protected]) wrote:
Quoted 9 lines · On Mon, 24 Sep 2007 11:56:35 -0700 Randy Dunlap wrote:
Quoted 8 lines · Christoph Hellwig
Quoted 6 lines · Randy Dunlap
I think that samples are perfectly fine for documentation and that the trace example is a good example. I think that most people who need something like that would need to customize it for their specific needs anyway.
We don't seem to be making progress...
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
Time to bring in a Tie-Breaker :)
Yes. Is anyone else interested? :(
I guess that's everyone (except those who are sleeping).
Let's not hold up progress. Just use
samples/for code.Would you already have the
Makefilesamples/Kconfigsamples/Makefile
Quoted 7 lines
Quoted 2 lines
core code handy per chance ? (and probably
Kconfigsourcing in every arch ?)Yes. Here it is. I'm working on add kprobes to it, but you can go ahead with markers also.
Hi Randy,
I got everything working and I'm thinking about posting all this stuff soon. Do you think your patch (having renamed Kbuild to Makefile) is ready to post ?
Mathieu
Quoted 334 lines
From: Randy Dunlap <[email protected]>
Begin infrastructure for kernel code samples in the
samples/directory. Add itsKconfigandKbuildfiles.
Source itsKconfigfile in allarch/Kconfigs.Signed-off-by Randy Dunlap <[email protected]>--- Makefile | 10 +++++++--- arch/alpha/Kconfig | 2 ++ arch/arm/Kconfig | 2 ++ arch/avr32/Kconfig | 2 ++ arch/blackfin/Kconfig | 2 ++ 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 | 3 ++- samples/Kbuild | 2 ++ samples/Kconfig | 11 +++++++++++ 28 files changed, 70 insertions(+), 4 deletions(-)Makefile +7
-3@@ -436,6 +436,7 @@ drivers-y := drivers/ sound/ net-y := net/ libs-y := lib/ core-y := usr/ +samples-y := samples/ endif # KBUILD_EXTMOD ifeq ($(dot-config),1)@@ -564,10 +565,12 @@ core-y += kernel/ mm/ fs/ ipc/ security vmlinux-dirs := $(patsubst %/,%,$(filter %/, $(init-y) $(init-m) \ $(core-y) $(core-m) $(drivers-y) $(drivers-m) \ - $(net-y) $(net-m) $(libs-y) $(libs-m))) + $(net-y) $(net-m) $(libs-y) $(libs-m)) \ + $(samples-y) $(samples-m)) + vmlinux-alldirs := $(sort $(vmlinux-dirs) $(patsubst %/,%,$(filter %/, \ - $(init-n) $(init-) \ + $(init-n) $(init-) $(samples-n) $(samples-) \ $(core-n) $(core-) $(drivers-n) $(drivers-) \ $(net-n) $(net-) $(libs-n) $(libs-))))@@ -578,6 +581,7 @@ net-y := $(patsubst %/, %/built-in.o, $ libs-y1 := $(patsubst %/, %/lib.a, $(libs-y)) libs-y2 := $(patsubst %/, %/built-in.o, $(libs-y)) libs-y := $(libs-y1) $(libs-y2) +samples-y := $(patsubst %/, %/built-in.o, $(samples-y)) # Build vmlinux # ---------------------------------------------------------------------------@@ -607,7 +611,7 @@ libs-y := $(libs-y1) $(libs-y2) # System.map is generated to document addresses of all kernel symbols vmlinux-init := $(head-y) $(init-y) -vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y) +vmlinux-main := $(core-y) $(libs-y) $(drivers-y) $(net-y) $(samples-y) vmlinux-all := $(vmlinux-init) $(vmlinux-main) vmlinux-lds := arch/$(ARCH)/kernel/vmlinux.lds export KBUILD_VMLINUX_OBJS := $(vmlinux-all)samples/Kbuild new file +2
-0@@ -0,0 +1,2 @@ +# Makefile for Linux samples code +samples/Kconfig new file +11
-0@@ -0,0 +1,11 @@ +# samples/Kconfig + +menuconfig SAMPLES + bool "Sample kernel code" + help + You can build and test sample kernel code here. + +if SAMPLES + + +endif # SAMPLESarch/alpha/Kconfig +2
-0@@ -669,5 +669,7 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"arch/arm/Kconfig +2
-0@@ -1067,4 +1067,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"arch/avr32/Kconfig +2
-0@@ -237,4 +237,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"arch/blackfin/Kconfig +2
-0@@ -1012,4 +1012,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"arch/cris/Kconfig +2
-0@@ -202,4 +202,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"arch/frv/Kconfig +2
-0@@ -381,4 +381,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"arch/h8300/Kconfig +2
-0@@ -229,4 +229,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"arch/i386/Kconfig +2
-0@@ -1260,6 +1260,8 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig" #arch/ia64/Kconfig +2
-0@@ -594,3 +594,5 @@ source "arch/ia64/Kconfig.debug" source "security/Kconfig" source "crypto/Kconfig" + +source "samples/Kconfig"arch/m32r/Kconfig +2
-0@@ -434,4 +434,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"arch/m68k/Kconfig +2
-0@@ -689,4 +689,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"arch/m68knommu/Kconfig +2
-0@@ -702,4 +702,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"arch/mips/Kconfig +2
-0@@ -1924,4 +1924,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"arch/parisc/Kconfig +2
-0@@ -275,4 +275,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"arch/powerpc/Kconfig +2
-0@@ -662,3 +662,5 @@ config KEYS_COMPAT default y source "crypto/Kconfig" + +source "samples/Kconfig"arch/ppc/Kconfig +2
-0@@ -1460,3 +1460,5 @@ source "arch/ppc/Kconfig.debug" source "security/Kconfig" source "crypto/Kconfig" + +source "samples/Kconfig"arch/s390/Kconfig +2
-0@@ -551,4 +551,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"arch/sh/Kconfig +2
-0@@ -739,4 +739,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"arch/sh64/Kconfig +2
-0@@ -293,6 +293,8 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig" #arch/sparc/Kconfig +2
-0@@ -333,4 +333,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"arch/sparc64/Kconfig +2
-0@@ -482,4 +482,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"arch/um/Kconfig +2
-0@@ -320,6 +320,8 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig" source "drivers/scsi/Kconfig"arch/v850/Kconfig +2
-0@@ -337,6 +337,8 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig" #############################################################################arch/x86_64/Kconfig +2
-0@@ -805,4 +805,6 @@ source "security/Kconfig" source "crypto/Kconfig" +source "samples/Kconfig" + source "lib/Kconfig"arch/xtensa/Kconfig +2
-1@@ -257,6 +257,7 @@ source "security/Kconfig" source "crypto/Kconfig" -source "lib/Kconfig" +source "samples/Kconfig" +source "lib/Kconfig"
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
Re: [patch 6/7] Linux Kernel Markers - Documentation
Quoted 33 lines · Mathieu Desnoyers
Quoted 21 lines · * Randy Dunlap ([email protected]) wrote:
Quoted 19 lines · On Mon, 24 Sep 2007 17:08:30 -0400 Mathieu Desnoyers wrote:
Quoted 9 lines · * Randy Dunlap ([email protected]) wrote:
Quoted 7 lines · On Mon, 24 Sep 2007 11:56:35 -0700 Randy Dunlap wrote:
Quoted 6 lines · Christoph Hellwig
Quoted 5 lines · Randy Dunlap
I think that samples are perfectly fine for documentation and that the trace example is a good example. I think that most people who need something like that would need to customize it for their specific needs anyway.
Quoted 7 lines
Quoted 3 lines
Quoted 2 lines
Quoted 1 line
We don't seem to be making progress...
Time to bring in a Tie-Breaker :)
Yes. Is anyone else interested? :(
I guess that's everyone (except those who are sleeping).
Let's not hold up progress. Just use
samples/for code.Would you already have the
Quoted 10 lines
Quoted 6 lines
Makefilesamples/Kconfigsamples/Makefilecore code handy per chance ? (and probably
Kconfigsourcing in every arch ?)Yes. Here it is. I'm working on add kprobes to it, but you can go ahead with markers also.
Quoted 5 lines
Hi Randy,
I got everything working and I'm thinking about posting all this stuff soon. Do you think your patch (having renamed
KbuildtoMakefile) is ready to post ?
Yes, AFAIK it is. Do you want me to resend it or do you want to make it patch M/N in your patches?
Signature · 2 lines
~Randy Phaedrus says that Quality is about caring.
Re: [patch 6/7] Linux Kernel Markers - Documentation
Quoted 34 lines · * Randy Dunlap ([email protected]) wrote:
Quoted 33 lines · Mathieu Desnoyers
Quoted 31 lines · * Randy Dunlap ([email protected]) wrote:
Quoted 17 lines · On Mon, 24 Sep 2007 17:08:30 -0400 Mathieu Desnoyers wrote:
Quoted 9 lines · * Randy Dunlap ([email protected]) wrote:
Quoted 7 lines · On Mon, 24 Sep 2007 11:56:35 -0700 Randy Dunlap wrote:
Quoted 6 lines · Christoph Hellwig
Quoted 5 lines · Randy Dunlap
I think that samples are perfectly fine for documentation and that the trace example is a good example. I think that most people who need something like that would need to customize it for their specific needs anyway.
Quoted 7 lines
Quoted 3 lines
Quoted 2 lines
Quoted 1 line
We don't seem to be making progress...
Time to bring in a Tie-Breaker :)
Yes. Is anyone else interested? :(
I guess that's everyone (except those who are sleeping).
Let's not hold up progress. Just use
samples/for code.Quoted 8 lines
Would you already have the
Makefilesamples/Kconfigsamples/Makefilecore code handy per chance ? (and probably
Kconfigsourcing in every arch ?)Yes. Here it is. I'm working on add kprobes to it, but you can go ahead with markers also.
Quoted 9 lines
Quoted 5 lines
Hi Randy,
I got everything working and I'm thinking about posting all this stuff soon. Do you think your patch (having renamed
KbuildtoMakefile) is ready to post ?Yes, AFAIK it is. Do you want me to resend it or do you want to make it patch M/N in your patches?
I'll include it with my patches. Thanks!
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
Re: [patch 6/7] Linux Kernel Markers - Documentation
In reply to Christoph HellwigQuoted 10 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.
As mentioned in the tracing infrastructure thread I don't think putting code into Documentation is a good idea. Either of you really should start a sample/ toplevel directory for this kind of stuff including a
Kconfigmenu etc to be able to build these samples as part of an allmodconfig.
One should have a look at Documentation/kprobes.txt for that kind of example code / documentation mix.
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
Re: [patch 6/7] Linux Kernel Markers - Documentation
Quoted 8 lines · Mathieu Desnoyers
Quoted 5 lines
putting code into Documentation is a good idea. Either of you really should start a sample/ toplevel directory for this kind of stuff including a
Kconfigmenu etc to be able to build these samples as part of an allmodconfig.One should have a look at
Documentation/kprobes.txtfor that kind of example code / documentation mix.
That one is particularly bad. It's high on my todo list of things to fix.
Re: [patch 6/7] Linux Kernel Markers - Documentation
Quoted 7 lines · On Mon, 24 Sep 2007 20:25:04 +0100 Christoph Hellwig wrote:
Quoted 6 lines · Mathieu Desnoyers
Quoted 5 lines
putting code into Documentation is a good idea. Either of you really should start a sample/ toplevel directory for this kind of stuff including a
Kconfigmenu etc to be able to build these samples as part of an allmodconfig.
Quoted 5 lines
Quoted 2 lines
One should have a look at
Documentation/kprobes.txtfor that kind of example code / documentation mix.That one is particularly bad. It's high on my todo list of things to fix. -
I already have it split and building. Just need to know
where to put it. :)
---
~Randy
Phaedrus says that Quality is about caring.
Re: [patch 6/7] Linux Kernel Markers - Documentation
In reply to Christoph HellwigQuoted 10 lines · Christoph Hellwig
Quoted 2 lines · Mathieu Desnoyers
Here is some documentation explaining what is/how to use the Linux Kernel Markers.
As mentioned in the tracing infrastructure thread I don't think putting code into Documentation is a good idea. Either of you really should start a sample/ toplevel directory for this kind of stuff including a
Kconfigmenu etc to be able to build these samples as part of an allmodconfig.
looking at Documentation/lguest/
Oh wait, nothing to see here. Move along please.
;-)
-- Steve
Re: [patch 6/7] Linux Kernel Markers - Documentation
Quoted 3 lines · Steven Rostedt
looking at
Documentation/lguest/Oh wait, nothing to see here. Move along please.
lguest is an even bigger nightmare. It's userspace code, but we can't move it because it pokes into non-exported headers.
PATCH 7/7 Port of blktrace to the Linux Kernel Markers.
In reply to Mathieu DesnoyersHere 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.
---
block/Kconfig | 1 block/blktrace.c | 343 ++++++++++++++++++++++++++++++++++++++++++- block/elevator.c | 6 block/ll_rw_blk.c | 35 ++-- drivers/block/cciss.c | 4 drivers/md/dm.c | 14 - fs/bio.c | 6 include/linux/blktrace_api.h | 145 +----------------- mm/bounce.c | 4 mm/highmem.c | 2 10 files changed, 388 insertions(+), 172 deletions(-)
block/elevator.c +3 -3
@@ -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;
@@ -735,7 +735,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 +19 -16
@@ -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> #include <linux/scatterlist.h>
@@ -1593,7 +1594,7 @@ void blk_plug_device(struct request_queuif (!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 ); } }
@@ -1659,7 +1660,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);
@@ -1671,7 +1672,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);
@@ -1681,7 +1682,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);
@@ -2201,7 +2202,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; }
@@ -2231,7 +2232,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);
@@ -2305,7 +2306,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);
@@ -3028,7 +3029,7 @@ static int __make_request(struct requestif (!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;
@@ -3045,7 +3046,7 @@ static int __make_request(struct requestif (!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;
@@ -3128,9 +3129,10 @@ static inline void blk_partition_remap(s bio->bi_sector += p->start_sect; bio->bi_bdev = bdev->bd_contains; -blk_add_trace_remap (bdev_get_queue (bio->bi_bdev), bio, - bdev->bd_dev, bio->bi_sector, - bio->bi_sector - p->start_sect); +trace_mark (blk_remap,"%p %p %llu %llu %llu" , +bdev_get_queue (bio->bi_bdev), bio, + (u64 )bdev->bd_dev, (u64 )bio->bi_sector, + (u64 )bio->bi_sector - p->start_sect); } }
@@ -3295,10 +3297,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;
@@ -3445,7 +3448,7 @@ static int __end_that_request_first(struint 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
@@ -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 +341 -2
380 lines not on this page · raw message
include/linux/blktrace_api.h +9 -136
165 lines not on this page · raw message
mm/bounce.c +2 -2
@@ -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 reif (!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
@@ -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
@@ -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
@@ -1072,8 +1072,8 @@ struct bio_pair *bio_split(struct bio *bif (!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
@@ -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>
@@ -2545,7 +2545,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
@@ -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 *iowake_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, - clone->bi_sector, 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
Quoted 6 lines · Mathieu Desnoyers
Hi Andrew,
Following Christoph Hellwig's suggestion, aiming at a Linux Kernel Markers inclusion for 2.6.24, I made a simplified version of the Linux Kernel Markers. There are no more dependencies on any other patchset.
Quoted 7 lines
The modification only involved turning the immediate values into static variables and adapting the documentation accordingly. It will have a little more data cache impact when disabled than the version based on the immediate values, but it is far less complex.
Since things have not moved much in the markers area recently (most of the concerns were about the immediate values), I expect it to be ready for 2.6.24.
I've done a quick review and except for my usual nitpicking it looks very good to me. I'll try my sputrace code with this version and will report on how it works.
I'd really love to see markers in 2.6.24. The impact to core code of the actual markers is minimal with some more struct fields in functions in the module code, although we'll want Mathieu's fix for the modules list aswell which is a little more invasive. But I think we want that one anyway.
I'd say we probably don't want the blktrace conversion that late in the game, though - but we can queue that once together with the optimizations from Mathieu's earlier patches in -mm.
Quoted 19 lines · * Christoph Hellwig ([email protected]) wrote:
Quoted 6 lines · Mathieu Desnoyers
Hi Andrew,
Following Christoph Hellwig's suggestion, aiming at a Linux Kernel Markers inclusion for 2.6.24, I made a simplified version of the Linux Kernel Markers. There are no more dependencies on any other patchset.
Quoted 7 lines
The modification only involved turning the immediate values into static variables and adapting the documentation accordingly. It will have a little more data cache impact when disabled than the version based on the immediate values, but it is far less complex.
Since things have not moved much in the markers area recently (most of the concerns were about the immediate values), I expect it to be ready for 2.6.24.
I've done a quick review and except for my usual nitpicking it looks very good to me. I'll try my sputrace code with this version and will report on how it works.
Quoted 6 lines
I'd really love to see markers in 2.6.24. The impact to core code of the actual markers is minimal with some more struct fields in functions in the module code, although we'll want Mathieu's fix for the modules list aswell which is a little more invasive. But I think we want that one anyway.
Well, since I just moved the marker iterators down in my patchset, I can move down the module list fix altogether and keep it for later. It will make the patchset as unintrusive as possible.
Quoted 4 lines
I'd say we probably don't want the blktrace conversion that late in the game, though - but we can queue that once together with the optimizations from Mathieu's earlier patches in -mm.
I provided blktrace as a first user of the markers, but I agree that it may be a little late for merging. I can keep it for later too.
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
Quoted 2 lines · Mathieu Desnoyers
I provided blktrace as a first user of the markers, but I agree that it may be a little late for merging. I can keep it for later too.
I we manage to get Dave's trace patches and your markers in I'll make sure to get a sputrace version using them in as a demo for both.
Quoted 7 lines · * Christoph Hellwig ([email protected]) wrote:
Quoted 2 lines · Mathieu Desnoyers
I provided blktrace as a first user of the markers, but I agree that it may be a little late for merging. I can keep it for later too.
I we manage to get Dave's trace patches and your markers in I'll make sure to get a sputrace version using them in as a demo for both.
Great!
So the state of the patches for next post:
kconfig-instrumentation.patch
linux-kernel-markers.patch
(yeah, only 2 patches!) :)
I'm only waiting for you guys to settle about documentation/samples before I can repost.
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