lkml.org 
[lkml]   [2008]   [Nov]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH 2/2] tracing/fastboot: Use the ring-buffer timestamp for initcall entries

On Wed, 12 Nov 2008, Ingo Molnar wrote:

>
> * Frederic Weisbecker <fweisbec@gmail.com> 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@gmail.com>
> > ---
> > 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



\
 
 \ /
  Last update: 2008-11-12 14:01    [W:0.246 / U:0.328 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site