Thursday | 8 January, 2009
LinuxWorld.com.au

Kernel space: The big kernel lock strikes again

A vestige of Linux's SMP past is still making trouble for users of heavily loaded systems. Developers say the solution isn't to fix the Big Kernel Lock, but to uproot it entirely. Will the mainstream kernel be able to agree on an approach to this surprisingly contentious issue?
Jonathan Corbet 21/05/2008 08:33:06

The reasoning behind this course of action would appear to be this: both semaphores and the BKL are old, deprecated mechanisms which are slated for minimization (semaphores) or outright removal (BKL) in the near future. Given that, it is not worth adding more complexity back into the semaphore code, which was dramatically simplified for 2.6.26. And, it seems, Linus is happy with a sub-optimal BKL:

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".

So the end result of all this may be a reinvigoration of the effort to remove the big kernel lock from the kernel. It still is not something which is likely to happen over the next few kernel releases: there is a lot of code which can subtly depend on BKL semantics, and there is no way to be sure that it is safe without auditing it in detail. And that is not a small job. Alan Cox has been reworking the TTY code for some time, but he has some ground to cover yet - and the TTY code is only part of the problem. So the BKL will probably be with us for a while yet.

More about Semaphore
Additional Resources
Newsletter Subscription
Sign up for our LinuxWorld newsletters!
RSS Feeds
 
Sponsored Links