Re: [PATCH 21/23 -v8] Add markers to various events

[Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>]

* Steven Rostedt (rostedt@goodmis.org) wrote:
> 5B
> 
> On Thu, 31 Jan 2008, Mathieu Desnoyers wrote:
> 
> > * Steven Rostedt (rostedt@goodmis.org) wrote:
> > > This patch adds markers to various events in the kernel.
> > > (interrupts, task activation and hrtimers)
> > >
> >
> > Hi Steven,
> >
> > I would propose the following standard for IRQ handler markers:
> >
> > trace_mark(kernel_irq_entry, "irq_id %u kernel_mode %u", irq,
> >   (regs)?(!user_mode(regs)):(1));
> 
> Are you saying that two markers with the same name is ok?
> That would be great if that is true.
> 

Yep. Just make sure that they have the exact same format string,
otherwise the marker infrastructure will refuse to connect probes to
them (and will printk an error message saying this). You can even put a
marker in an inline function or unrolled loop (many markers will be
generated and this is ok).

> > ....
> > trace_mark(kernel_irq_exit, MARK_NOARGS);
> 
> My patches don't use this (yet) so I'm leaving out adding markers
> that are not used. I'm not disagreeing with adding these, it's just that
> a patch series should only add markers that are actually used.
> 

Ok, I agree with your approach. About using the markers, I wonder if it
would be best for me to continue to concentrate my effort in getting the
low-level stuff into the kernel first or to switch my focus on posting
the higher-level stuff : the tracer itself, which is mostly a
stand-alone kernel module.

Mathieu

> >
> > So we can know the elaspsed time in irq handlers and whether they are
> > nested on user of kernel code.
> >
> > The same for traps :
> >
> > trace_mark(kernel_arch_trap_entry, "trap_id %d ip #p%ld", trapnr,
> >   instruction_pointer(regs));
> >
> > Where we know the trap number and the instruction pointer that caused
> > the trap. Here again, we should put a :
> >
> > trace_mark(kernel_arch_trap_exit, MARK_NOARGS);
> >
> > At the end of the trap handlers.
> >
> > It makes automatic analysis _much_ easier than trying to gather each and
> > every handler instrumentation which would have a different name...
> >
> 
> -- Steve
> 

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