Might 2.6.35 be BKL-free?

The removal of the big kernel lock (BKL) has been one of the longest-running projects in kernel development history. The BKL has been a clear scalability and maintainability problem since its addition in the 1.3 development series; efforts to move away from it began in the 2.1 cycle. But the upcoming 2.6.34 kernel will still feature a big kernel lock, despite all the work that has been done to get rid of it. The good news is that 2.6.35 might just work without the BKL - at least, for a number of configurations.

Over the years, use of the BKL has been pushed down into ever lower levels of the kernel. Once a lock_kernel() call has been pushed into an individual device driver, for example, it is relatively easy to determine whether it is really necessary and, eventually, get rid of it altogether. There is, however, one significant BKL acquisition left in the core kernel: the ioctl() implementation. The kernel has supported a BKL-free unlocked_ioctl() operation for years, but there are still many drivers which depend on the older, BKL-protected version.

Clearly, fixing the ioctl() problem is a key part of the overall BKL solution. To that end, Frederic Weisbecker and Arnd Bergmann posted a patch to prepare the ground for change. This patch adds yet another ioctl() variant called locked_ioctl() to the file_operations structure. The idea was to have both ioctl() and locked_ioctl() in place for long enough to change all of the code which still requires the BKL, after which ioctl() could be removed. This new function was also made dependent on a new CONFIG_BKL configuration option.

That patch did not get very far; Linus strongly disliked both locked_ioctl() and CONFIG_BKL. So the search for alternatives began. In the end, it looks like locked_ioctl() may never happen, but the configuration option will eventually exist.

Linus's suggestion was to not bother with locked_ioctl(). Instead, every ioctl() operation should just be renamed to bkl_ioctl() in one big patch. That would allow code which depends on the BKL to be easily located with grep without adding yet another function to struct file_operations even temporarily. A patch which does this renaming has been posted; this patch may well be merged for 2.6.35.

Or perhaps not. Arnd has taken a more traditional approach with his patch which simply pushes the BKL down into every remaining ioctl() function which needs it. Once a specific ioctl() function handles BKL acquisition itself, it can be called from the core kernel as an unlocked_ioctl() function instead. When all such functions have been converted, the locked version of ioctl() can go away, and the BKL can be removed from that bit of core code. The pushdown is a bigger job than the renaming, but it accomplishes a couple of important goals.

One of those goals is simply getting the BKL closer to the code which depends on it, facilitating its eventual removal. The other is to get that much closer to a point where the BKL can simply be configured out of the kernel altogether. That is where the CONFIG_BKL option comes in. Turning that option off will remove BKL support, causing any code which depends on it to fail to compile. That code can be annotated with its BKL dependency, again making it easier to find and fix.

On the face of it, configuring out the BKL may not seem like a hugely desirable thing to do; it takes little space, and the overhead seems small if nobody is actually using it. But there is small - but significant - savings to be had: currently the scheduler must check, at every context switch, whether the BKL must be released by the outgoing process and/or reacquired by the incoming process. Context switches happen often enough that it's worth making them as fast as possible; eliminating the BKL outright will make a small contribution toward that goal.

Making the BKL configurable will also be a motivating factor for anybody who finds that their BKL-free kernel build is blocked by one crufty old driver. Most of the remaining BKL-dependent drivers are unloved and unmaintained; many of them may be entirely unused. Those which are still being used may well be fixed once a suitably-skilled developer realizes that a small amount of work will suffice to banish the BKL from a specific system forevermore.

In the end, 2.6.35 will not be, as a whole, a BKL-free kernel. But, if this work gets in, and if some other core patches are accepted, it may just become possible to build a number of configurations without the big kernel lock. That, certainly, is an achievement worth celebrating.

---

(Log in to post comments)