The Big Kernel Lock lives on [LWN.net]

The Big Kernel Lock lives on

Posted May 27, 2004 4:21 UTC (Thu) by ncm (subscriber, #165)
Parent article: The Big Kernel Lock lives on

Would somebody please explain, briefly, how the BKL and its users interact with the (approximately) myriad other locks in the kernel? I.e. does the BKL only guard what is not guarded by any other lock? Might a driver need to take the BKL and another, finer-grained lock, before proceeding? Is there a natural order in which locks are taken?

(Log in to post comments)

The Big Kernel Lock lives on

Posted May 27, 2004 11:24 UTC (Thu) by kunitz (guest, #3965) [Link]

Alan Cox, I believe, emphasized: Locks protect data; not threads. As long as two threads don't access the same data, they are not required to share the same lock. Today most of the kernel data is protected by granular locks; however there is still data protected by the big kernel lock. So finding all the users of the big kernel lock is the easy part, you must find out which data is actually protected and you must introduce granular locks to protect that data.

Even in the pre-SMP times you had to lock data against interrupt handlers. Linus simply disabled and enabled interrupts in the critical sections using the infamous cli()/sti() pairs. I believe, the simplicity of that solution inspired the big kernel lock.

The Big Kernel Lock lives on

Posted May 27, 2004 11:54 UTC (Thu) by corbet (editor, #1) [Link]

The BKL is a special lock; its purpose still, essentially, is to protect resources not covered by some other lock. Modern code running under the BKL may well take other locks, but it will be unaware of it - the locks will be taken further down the call chain. Once the code itself becomes lock-aware, the need for the BKL should go away.

And yes, it is actually quite important to define the order in which locks are taken. If the same two locks can be taken in either order, the system will eventually deadlock. Lock ordering rules (and, in general, figuring out which locks you need) get to be a real problem as the number of locks grows; people like Larry McVoy have been warning for years that overly fine-grained locking leads to an unmaintainable kernel.

The Big Kernel Lock lives on

Posted May 27, 2004 12:33 UTC (Thu) by brugolsky (subscriber, #28) [Link]

I'm sure that you meant this, but just to clarify: fine-grained locks, in and of themselves, are not the problem. One can lock a list, or lock the individual elements; the choice generally impacts performance. Excessive lock depth (i.e., level of nesting) results in an unmaintainable code. It seems to be generally agreed that the cliff lies not far beyond four locks.

The Big Kernel Lock lives on

Posted May 27, 2004 23:43 UTC (Thu) by nix (subscriber, #2304) [Link]

`Seven, plus or minus two'... and since we don't want to restrict kernel maintainership to those who are lucky enough to have big short-term memories, less than five seems a good point to stop.

The Big Kernel Lock lives on

Posted Jun 2, 2004 22:30 UTC (Wed) by shane (subscriber, #3335) [Link]

Not to speak for Mr. Corbet, but I'm pretty sure he actually was
referring to having too many locks. The problem is deadlock: one thread
holding lock A, waiting for lock B; the other holding lock B, waiting for
lock A. This is the simplest example (well, holding A and waiting for A
is simpler, but you get the idea). Any circular chain of references is
possible, and causes the same problem.

This problem is easier to hit when you use many different locks. A
programmer's natural inclination is to lock each resource as you need it.
However, in order to prevent deadlock you should always lock in the same
order. Which means that if any thread ever needs lock A and lock B, it
always locks A and then lock B. This is not always optimal, as lock A
may be held for a period of time when it is not needed.