Re: Problem with CREATE_TRACE_POINTS and recursion safety

[Jeremy Fitzhardinge]

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/