Status of the Big Kernel Lock

Linus Torvalds posted a patch to undo a large change to the kernel's locking system. The big kernel lock (BKL) had been changed from a spinlock, with some latency issues, to a semaphore. This had been a big win for folks doing work supporting patient monitors in hospitals (or playing first-person shooters).

The semaphore solution caused huge performance problems under certain benchmarks, and the solutions to these performance issues still left lingering problems. So Linus decided that the simple way out was to go back to the way things had been before the change.

Linus also indicated that the only way around the spinlock approach would be to eliminate the BKL entirely. Ingo Molnar, a self-proclaimed "latency junkie," was not pleased with this, but he accepted Linus's premise that the solution was to pull out the BKL at the root. It turns out ditching the BKL is hard! It took people with the raw talent of Alan Cox (quoth Ingo) to wind their way through the maze of semantics in order to know what to change and how to change it. According to Ingo's calculations, even with folks like Alan already hard at work on the task, at the current pace, it would be more than 10 years before the BKL was gone. Ingo explained the problem, saying, "… its dependencies are largely unknown and invisible, and it is all lost in the haze of the past ~15 years of code changes. All this has built up to a kind of Fear, Uncertainty, and Doubt about the BKL: nobody really knows it, nobody really dares to touch it, and code can break silently and subtly if BKL locking is wrong."

Ingo's solution was to create a git tree specifically to rein in some of the more horrifying BKL oddities, with the goal of ultimately making the BKL easier to remove en masse. One of the main first steps was to extract it from the core kernel code and move all its ugliness into something that could one day theoretically be replaced on its own, changing the behavior throughout the kernel once an improved implementation could be designed. As Ingo put it, "Once this tree stabilizes, elimination of the BKL can be done the usual and well-known way of eliminating big locks – by pushing it down into subsystems and replacing it with subsystem locks, and splitting those locks and eliminating them. We've done this countless times in the past and there are lots of capable developers who can attack such problems."

Andi Kleen liked the plan, but figured why wait? Instead of having a separate git tree for all the changes, just do them in the official branch. Linus was also pleased to see Ingo working on this and had some suggestions about how to organize the git tree. A bunch of other high-powered hackers also turned their attention to the various technical issues involved.