|| ||Linus Torvalds <torvalds-AT-linux-foundation.org>|
|| ||Alan Cox <alan-AT-lxorguk.ukuu.org.uk>|
|| ||Re: AIM7 40% regression with 2.6.26-rc1|
|| ||Wed, 7 May 2008 08:00:04 -0700 (PDT)|
|| ||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>,
Alexander Viro <viro-AT-ftp.linux.org.uk>,
Andrew Morton <akpm-AT-linux-foundation.org>|
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".
to post comments)