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
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
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
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
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
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
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.
to post comments)