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 08:47:46 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Frederic Weisbecker <fweisbec@...il.com>
cc:	Ingo Molnar <mingo@...e.hu>, 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, 1 Mar 2010, Frederic Weisbecker wrote:

> On Mon, Mar 01, 2010 at 09:00:58AM +0100, Ingo Molnar wrote:
> > 
> > 	if (smp_processor_id() == 7)
> > 		ftrace_enabled = 1;
> > 
> > 	... bootup sequence ...
> > 
> > 	if (smp_processor_id() == 7)
> > 		ftrace_enabled = 0;

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

Both of you seemed to miss the fact that it's not cpu7 that is 
particularly slow. See the original email from me in this thread: the jump 
was at some random point:

        [    0.245179] CPU 1 MCA banks CMCI:2 CMCI:3 CMCI:5 SHD:6 SHD:8
        [    0.265332]  #2
        [    0.353185] CPU 2 MCA banks CMCI:2 CMCI:3 CMCI:5 SHD:6 SHD:8
        [    0.373328]  #3
        [    2.193277] CPU 3 MCA banks CMCI:2 CMCI:3 CMCI:5 SHD:6 SHD:8
        [    2.213379]  #4

and the reason I grepped for "CPU 7" was that it's the _last_ CPU on this 
machine, so what I was grepping for was basically "how long did it take to 
bring up all CPU's".

So that particular really bad case apparently happened for CPU#3, but the 
two other slow cases happened for CPU#4.

Also, it seems to happen only about every fifth boot or so. Suggestions 
for something simple that can trace things like that?

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