lkml.org 
[lkml]   [2008]   [May]   [7]   [last100]   RSS-feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
Complete thread (EXPERIMENTAL)
/
DateWed, 7 May 2008 19:05:28 +0200
FromIngo Molnar <>
SubjectRe: AIM7 40% regression with 2.6.26-rc1
Digg This

* Linus Torvalds <torvalds@linux-foundation.org> wrote:
I think it is far more likely that it's due to the different scheduling and wakeup behavior of the new kernel/semaphore.c code. So the fix would be to restore the old scheduling behavior - that's what Yanmin's manual revert did and that's what got him back the previous AIM7 performance.

Yes, Yanmin's manual revert got rid of the new semaphores entirely. Which was what, 7500 lines of code removed that got reverted.

i wouldnt advocate a 7500 revert instead of a 160 lines change.
my suggestion was that the scheduling behavior of the new kernel/semaphore.c code is causing the problem - i.e. making it match the old semaphore code's behavior would give us back performance.
And the *WHOLE* and *ONLY* excuse for dropping the spinlock lock_kernel was this (and I quote your message):

remove the !PREEMPT_BKL code.

this removes 160 lines of legacy code.

in other words, your only stated valid reason for getting rid of the spinlock was 160 lines, and the comment didn't even match what it did (it removed the spinlocks entirely, not just the preemptible version).

it was removed by me in the course of this discussion:
http://lkml.org/lkml/2008/1/2/58

the whole discussion started IIRC because !CONFIG_PREEMPT_BKL [the spinlock version] was broken for a longer period of time (it crashed trivially), because nobody apparently used it. People (Nick) asked why it was still there and i agreed and removed it. CONFIG_PREEMPT_BKL=y was the default, that was what all distros used. I.e. the spinlock code was in essence dead code at that point in time.

the spinlock code might in fact perform _better_, but nobody came up with such a workload before.

In contrast, the revert adds 7500 lines. If you go by the only documented reason for the crap that is the current BKL, then I know which one I'll take. I'll take the spinlock back, and I'd rather put preemption back than ever take those semaphores.

And even that's ignoring another issue: did anybody ever even do that AIM7 benchmark comparing spinlocks to the semaphore-BKL? It's quite possible that the semaphores (even the well-behaved ones) behaved worse than the spinlocks.

that's a good question...

Ingo



\
ISP Services
Valid XHTML 1.0!\ /
Valid CSS! Last update: 2008-05-07 19:09    [W:0.629 / U:0.000 seconds]
©2003-2005 Jasper Spaans