linux-kernel - Re: [GIT PULL] x86/cpu changes for v2.6.34

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <1267471766.10871.4.camel@gandalf.stny.rr.com>
Date:	Mon, 01 Mar 2010 14:29:26 -0500
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Frederic Weisbecker <fweisbec@...il.com>
Cc:	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org, "H. Peter Anvin" <hpa@...or.com>,
	Borislav Petkov <borislav.petkov@....com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT PULL] x86/cpu changes for v2.6.34

On Mon, 2010-03-01 at 14:17 +0100, Frederic Weisbecker wrote:
> On Mon, Mar 01, 2010 at 09:00:58AM +0100, Ingo Molnar wrote:
> > Weird. It seems to be around multiples of .8: 0.8, 1.6, 2.4, with some extra 
> > overhead.
> > 
> > Almost as if some calibration routine or some other busy-loop misses the train 
> > occasionally.
> > 
> > The way i'd go about debugging this is to narrow down the approximate place 
> > the slowdown happens, then enable CONFIG_FUNCTION_TRACER (and disable 
> > CONFIG_DYNAMIC_FTRACE=y, to not have to deal with the dynamic patching 
> > aspects), and do a single-shot tracing session of only that section, on only 
> > one CPU:
> > 
> > 	if (smp_processor_id() == 7)
> > 		ftrace_enabled = 1;
> > 
> > 	... bootup sequence ...
> > 
> > 	if (smp_processor_id() == 7)
> > 		ftrace_enabled = 0;
> > 
> > And recover the resulting trace from /debug/tracing/trace - it should have the reason
> > in it plain and simple.
> > 
> > ( Unfortunately i'm not 100% sure that setting ftrace_enabled to 1 is enough. 
> >   I asked for a simple ad-hoc enable/disable function tracing mechanism _ages_ 
> >   ago - Steve, Frederic, what happened to that? ftrace_start()/stop() does not 
> >   seem to allow that. )
> 

Setting ftrace_enabled = 0 should stop the function tracer, but may not
stop the function graph tracer.

> 
> 
> I don't remember such request. But that would be useful indeed.
> We could simply pair the setting of an early tracer with tracing
> disabled and then manually delimit the places to trace with
> tracing_on/tracing_off().

It's best to use tracing_off() and tracing_on() for such things.

> 
> Whatever.
> 
> For now what you can do is setting the function_graph tracer
> on bootup:
> 
> 	ftrace=function_graph
> 
> and call ftrace_graph_stop() in the place you want the trace

tracing_off() is the best API for this. Although you still have the
overhead of the tracer. But you can just
 echo nop > /debug/tracing/current_tracer
to remove the overhead after bootup.

-- Steve

> to finish (you could use ftrace_graph_filter= to delimit
> the function tracing window, but that won't work without
> dynamic tracing, neither with __init functions).
> 
> So, after the boot you can look at /debug/tracing/per_cpu/cpu7/trace
> and the end of the trace should contain what you want.
> 


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