On Mon, 6 Oct 2008, Zhang, Yanmin wrote:
quoted text
> 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@linutronix.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.

There is a fixup patch for this one after rc8. 07454bfff151d2465ada809bbaddf3548cc1097c
Can you check with this one applied please ?

Thanks,

	tglx
--
unsubscribe notice
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/