[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <1223269135.1685.11.camel@ymzhang>
Date: Mon, 06 Oct 2008 12:58:55 +0800
From: "Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: LKML <linux-kernel@...r.kernel.org>
Subject: aim7 47% regression with 2.6.27-rc8
Comparing with 2.6.27-rc8, aim7 result has about 47% regression with 2.6.27-rc8 on
my 16-core tigerton and 8 core+HyperThreading x86_64 machine.
I bisected it down to patch:
302745699c1b675b5d2a1af87271de10e4d96b6a is first bad commit
commit 302745699c1b675b5d2a1af87271de10e4d96b6a
Author: Thomas Gleixner <tglx@...utronix.de>
Date: Mon Sep 22 19:02:25 2008 +0200
clockevents: check broadcast device not tick device
Impact: Possible hang on CPU online observed on AMD C1E machines.
The broadcast setup code looks at the mode of the tick device to
determine whether it needs to be shut down or setup. This is wrong
when the broadcast mode is set to one shot already. This can happen
when a CPU is brought online as it goes through the periodic setup
first.
The problem went unnoticed as sane systems do not call into that code
before the switch to one shot for the clock event device happens.
The AMD C1E idle routine switches over immediately and thereby shuts
down the just setup device before the first interrupt happens.
After I reverted the patch against 2.6.27-rc8, the regression disappears.
It's interesting that the regression doesn't exist on 8-core stoakley.
-yanmin
--
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/
Powered by blists - more mailing lists