Re: Problem with CREATE_TRACE_POINTS and recursion safety
From: Jeremy Fitzhardinge
Date: Wed Apr 15 2009 - 21:06:20 EST
Steven Rostedt wrote:
On Wed, 15 Apr 2009, Jeremy Fitzhardinge wrote:
I'm having a problem with CREATE_TRACE_POINTS being too indiscriminate. The
trouble is that it not only creates tracepoint definitions for the intended
tracepoints, but any other tracepoint definitions which get included
incidentally.
For example, I'm seeing my paravirt tracepoints being instantiated in both
kernel/sched.o and kernel/irq/manage.o as side-effects of the scheduler and
irq tracepoints being instantiated.
I'm experimenting with a different scheme, wherein a subsystem defines
CREATE_FOO_TRACE_POINTS in the .c file where it wants to instantiate the
tracepoints - rather than CREATE_TRACE_POINTS - and its trace/events/foo.h
does:
#ifdef CREATE_FOO_TRACE_POINTS
#undef CREATE_FOO_TRACE_POINTS /* avoid infinite recursion */
#include <trace/instantiate_trace.h>
#else
#include <trace/define_trace.h>
#endif
where instantiate_trace.h is:
#define CREATE_TRACE_POINTS
#include <trace/define_trace.h>
#undef CREATE_TRACE_POINTS
(Just to prevent a bit more repeated boilerplate in each events definition
file.)
This seems to work. (Update: no it doesn't. WTF has paravirt-trace.o got
duplicate kmem tracepoints?!)
kmem was a PITA. Looks like we might need to do a:
#ifdef CREATE_FOO_TRACE_POINTS
#include <trace/define_trace.h>
#endif
The sched and irq tracepoints have the same general problem.
type of thing, and have each user define their own CREATE_FOO_TRACE_POINTS
that they want to instantiate. This should be a requirement on any
trace point header that is used in other headers.
Does just adding the above to the kmem.h header and your header fix it for
you?
No, I have a complete patch to do what I'm proposing here, and kmem went
ahead and failed anyway. I'll post a cleaned up set of RFC patches and
try to track down what's happening later.
And there seems to be a secondary problem with kmem tracepoints being
called without an explicit #include of <trace/events/kmem.h>, so I'm
seeing compiler errors relating to that too:
CC arch/x86/kernel/paravirt-trace.o
In file included from /home/jeremy/git/linux/include/linux/slab.h:165,
from /home/jeremy/git/linux/include/linux/percpu.h:6,
from /home/jeremy/git/linux/include/linux/vmstat.h:6,
from /home/jeremy/git/linux/include/linux/mm.h:596,
from /home/jeremy/git/linux/include/linux/ring_buffer.h:6,
from /home/jeremy/git/linux/include/linux/ftrace_event.h:6,
from /home/jeremy/git/linux/include/trace/ftrace.h:20,
from /home/jeremy/git/linux/include/trace/define_trace.h:64,
from /home/jeremy/git/linux/include/trace/instantiate_trace.h:7,
from /home/jeremy/git/linux/include/trace/events/pvops.h:1186,
from /home/jeremy/git/linux/arch/x86/kernel/paravirt-trace.c:5:
/home/jeremy/git/linux/include/linux/slab_def.h: In function 'kmalloc':
/home/jeremy/git/linux/include/linux/slab_def.h:157: error: implicit declaration of function 'trace_kmalloc'
Also, the pvops trace stuff adds quite a lot of overhead to the kernel
size - and probably runtime - so I think we'll need to have Kconfig
switches for each set of trace events rather than a single fat
CONFIG_TRACEPOINTS switch.
J
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/