aim7 47% regression with 2.6.27-rc8

["Zhang, Yanmin" <yanmin_zhang@xxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxx>
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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/