Re: AIM7 40% regression with 2.6.26-rc1
[Posted May 13, 2008 by corbet]
| From: |
| Linus Torvalds <torvalds-AT-linux-foundation.org> |
| To: |
| Alan Cox <alan-AT-lxorguk.ukuu.org.uk> |
| Subject: |
| Re: AIM7 40% regression with 2.6.26-rc1 |
| Date: |
| Wed, 7 May 2008 08:00:04 -0700 (PDT) |
| Message-ID: |
| <alpine.LFD.1.10.0805070757170.32269@woody.linux-foundation.org> |
| Cc: |
| Andi Kleen <andi-AT-firstfloor.org>, Matthew Wilcox <matthew-AT-wil.cx>,
"Zhang, Yanmin" <yanmin_zhang-AT-linux.intel.com>,
Ingo Molnar <mingo-AT-elte.hu>,
LKML <linux-kernel-AT-vger.kernel.org>,
Alexander Viro <viro-AT-ftp.linux.org.uk>,
Andrew Morton <akpm-AT-linux-foundation.org> |
| Archive‑link: | |
Article |
On Wed, 7 May 2008, Alan Cox wrote:
>
> > But my preferred option would indeed be just turning it back into a
> > spinlock - and screw latency and BKL preemption - and having the RT people
> > who care deeply just work on removing the BKL in the long run.
>
> It isn't as if the RT build can't use a different lock type to the
> default build.
Well, considering just *how* bad the new BKL apparently is, I think that's
a separate issue. The semaphore implementation is simply not worth it. At
a minimum, it should be a mutex.
> > Is BKL preemption worth it? Sounds very dubious. Sounds even more dubious
> > when we now apparently have even more reason to aim for removing the BKL
> > rather than trying to mess around with it.
>
> We have some horrible long lasting BKL users left unfortunately.
Quite frankly, maybe we _need_ to have a bad BKL for those to ever get
fixed. As it was, people worked on trying to make the BKL behave better,
and it was a failure. Rather than spend the effort on trying to make it
work better (at a horrible cost), why not just say "Hell no - if you have
issues with it, you need to work with people to get rid of the BKL
rather than cluge around it".
Linus
