lkml.org 
[lkml]   [2010]   [Mar]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [GIT, RFC] Killing the Big Kernel Lock
    On Wed, Mar 24, 2010 at 10:40:54PM +0100, Arnd Bergmann wrote:
    > I've spent some time continuing the work of the people on Cc and many others
    > to remove the big kernel lock from Linux and I now have bkl-removal branch
    > in my git tree at git://git.kernel.org/pub/scm/linux/kernel/git/arnd/playground.git
    > that lets me run a kernel on my quad-core machine with the only users of the BKL
    > being mostly obscure device driver modules.
    >
    > The oldest patch in this series is roughly eight years old and is Willy's patch
    > to remove the BKL from fs/locks.c, and I took a series of patches from Jan that
    > removes it from most of the VFS.
    >
    > The other non-obvious changes are:
    >
    > - all file operations that either have an .ioctl method or do not have their
    > own .llseek method used to implicitly require the BKL. I've changed that
    > so they need to explicitly set .llseek = default_llseek, .unlocked_ioctl =
    > default_ioctl, and changed all the code that either has supplied a .ioctl
    > method or looks like it needs the BKL somewhere else, meaning the
    > default_llseek function might actually do something.
    >
    > - The block layer now has a global bkldev_mutex that is used in all block
    > drivers in place of the BKL. The only recursive instance of the BKL was
    > __blkdev_get(), which is now called with the blkdev_mutex held instead of
    > grabbing the BKL. This has some possible performance implications that
    > need to be looked into.
    >
    > - The init/main.c code no longer take the BKL. I figured that this was
    > completely unnecessary because there is no other code running at the
    > same time that takes the BKL.
    >
    > - The most invasive change is in the TTY layer, which has a new global
    > mutex (sorry!). I know that Alan has plans of his own to remove the BKL
    > from this subsystem, so my patches may not go anywhere, but they seem
    > to work fine for me.
    > I've called the new lock the 'Big TTY Mutex' (BTM), a name that probably
    > makes more sense if you happen to speak German.
    > The basic idea here is to make recursive locking and the release-on-sleep
    > explicit, so every mutex_lock, wait_event, workqueue_flush and schedule
    > in the TTY layer now explicitly releases the BTM before blocking.
    >
    > - All drivers that still require the BKL are now listed as 'depends on BKL'
    > in Kconfig, and you can set that symbol to 'y', 'm' or 'n'. If the lock
    > itself is a module, only other modules can use it, and /proc/modules
    > will tell you exactly which ones those are. I've thought about adding
    > a module_init function in that module that will taint the kernel, but so
    > far I haven't done that.
    >
    > - Included is a debugfs file that gives statistics over the BKL usage from
    > early boot on. This is now obsolete and will not get merged, but I'm
    > including it for reference.
    >
    > Frederic has volunteered to help merging all of this upstream, which I
    > very much welcome. The shape that the tree is in now is very inconsistent,
    > especially some of the bits at the end are a bit dodgy and all of it needs
    > more testing.
    >
    > I've built-tested an allmodconfig kernel with CONFIG_BKL disabled
    > on x86_64, i386, powerpc64, powerpc32, s390 and arm to make sure I
    > catch all the modules that depend on BKL, and I've been running
    > various versions of this tree on my desktop machine over the last few
    > weeks while adding stuff.
    >
    > Arnd
    >
    > ---
    >
    > Arnd Bergmann (44):
    > input: kill BKL, fix input_open_file locking
    > ptrace: kill BKL
    > procfs: kill BKL in llseek
    > random: forbid llseek on random chardev
    > x86/microcode: use nonseekable_open
    > perf_event: use nonseekable_open



    I just queued the perf_event one. It looks pretty good. I'm also
    looking at some of the most trivials (ehm..less hards) in the list
    and see which we can submit right away.

    Thanks.



    \
     
     \ /
      Last update: 2010-03-28 22:07    [W:4.182 / U:0.352 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site