Re: [PATCH 2/2] tracing/fastboot: Use the ring-buffer timestamp forinitcall entries

[Steven Rostedt]

On Wed, 12 Nov 2008, Ingo Molnar wrote:

> 
> * Frederic Weisbecker <fweisbec@xxxxxxxxx> wrote:
> 
> > Impact: Split the boot tracer entries in two parts: call and return
> > 
> > Now that we are using the sched tracer from the boot tracer, we want 
> > to use the same timestamp than the ring-buffer to have consistent 
> > time captures between sched events and initcall events. So we get 
> > rid of the old time capture by the boot tracer and split the 
> > initcall events in two parts: call and return. This way we have the 
> > ring buffer timestamp of both.
> > 
> > There is an example of a trace in attachment.
> > 
> > Signed-off-by: Frederic Weisbecker <fweisbec@xxxxxxxxx>
> > ---
> >  include/trace/boot.h      |   31 ++++++++---
> >  init/main.c               |   32 ++++++------
> >  kernel/trace/trace.h      |   17 ++++--
> >  kernel/trace/trace_boot.c |  123 ++++++++++++++++++++++++++++++++++-----------
> >  4 files changed, 144 insertions(+), 59 deletions(-)
> 
> applied	to tip/tracing/fastboot, thanks	Frederic! 
> 
> one small detail, do we need these messages in the boot tracer:
> 
>   ##### CPU 1 buffer started ####
> 
> they are helpful for latency traces but might be confusing for boot 
> traces. (they lose their attraction after having seen a dozen of them)

Yeah, I was thinking of putting in a iter_ctrl to disable them. But then, 
should they be on or off by default?

The pro for having them off by default, they are not as distracting.

The con for having them off by default, they lose their meaning, and 
developers get confused when they see CPU 1 starting after 100 prints of 
CPU0, when they both should have started.

-- Steve

--
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/