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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20081112130122.GA23798@elte.hu>
Date:	Wed, 12 Nov 2008 14:01:22 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Steven Rostedt <rostedt@...dmis.org>
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


* Steven Rostedt <rostedt@...dmis.org> wrote:

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

i think they are useful to be included for most of the tracers, except 
the boot tracer (which starts/stop with high frequency). So i'd 
suggest to keep the default, but also to expose it in an iter_ctl plus 
dynamically turn it off for the boot tracer.

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