linux-kernel - Re: [PATCH 2/2] tracing/fastboot: Use the ring-buffer timestamp for initcall entries

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 12 Nov 2008 07:59:28 -0500 (EST)
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Ingo Molnar <mingo@...e.hu>
cc:	Frederic Weisbecker <fweisbec@...il.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 2/2] tracing/fastboot: Use the ring-buffer timestamp for
 initcall entries


On Wed, 12 Nov 2008, Ingo Molnar wrote:

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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/