Zack's Kernel News

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.

Buy this article as PDF

Express-Checkout as PDF
Price $2.95
(incl. VAT)

Buy Linux Magazine

Get it on Google Play

US / Canada

Get it on Google Play

UK / Australia

Related content

  • Kernel News


  • Kernel News


  • Kernel News

    Chronicler Zack Brown reports on the latest news, views, dilemmas, and developments within the Linux kernel community.


    The Linux kernel mailing list comprises the core of Linux development activities. Traffic volumes are immense, often reaching ten thousand messages in a given week, and keeping up to date with the entire scope of development is a virtually impossible task for one person. One of the few brave souls to take on this task is Zack Brown. Our regular monthly column keeps you abreast of the latest discussions and decisions, selected and summarized by Zack. Zack has been publishing a weekly online digest, the Kernel Traffic news letter for over five years now. Even reading Kernel Traffic alone can be a time consuming task. Linux Magazine now provides you with the quintessence of Linux Kernel activities, straight from the horse’s mouth.

comments powered by Disqus

Direct Download

Read full article as PDF:

014-015_kernel.pdf  (562.62 kB)
Subscribe to our Linux Newsletters
Find Linux and Open Source Jobs
Subscribe to our ADMIN Newsletters

Support Our Work

Linux Magazine content is made possible with support from readers like you. Please consider contributing when you've found an article to be beneficial.