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]

Date:	Mon, 1 Mar 2010 14:17:05 +0100
From:	Frederic Weisbecker <fweisbec@...il.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Steven Rostedt <rostedt@...dmis.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, 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. )



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

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