lkml.org 
[lkml]   [2008]   [May]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [announce] "kill the Big Kernel Lock (BKL)" tree
    From
    Date
    Sez Ingo:

    > This task is not easy at all. 12 years after Linux has been converted to
    > an SMP OS we still have 1300+ legacy BKL using sites. There are 400+
    > lock_kernel() critical sections and 800+ ioctls.

    There's also every char device open() method - a rather long list in its
    own right. I'd be surprised if one in ten of them really needs it, but
    one has to look...

    I've been looking at the chrdev code anyway, and pondering on how this
    might be addressed. Here's some thoughts on alternatives, I'd be
    curious what people think:

    1: We could add an unlocked_open() to the file_operations structure;
    drivers could be converted over as they are verified not to need the
    BKL on open. Disadvantages are that it grows this structure for a
    relatively rare case - most open() calls already don't need the BKL.
    But it's a relatively easy path without flag days.

    2: Create a char_dev_ops structure for char devs and use it instead of
    file_operations. I vaguely remember seeing Al mutter about that a
    while back. Quite a while back. This mirrors what was done with
    block devices, and makes some sense - there's a lot of stuff in
    struct file_operations which is not really applicable to char devs.
    Then struct char_dev_ops could have open() and locked_open(), with
    the latter destined for removal sometime around 2015 or so.

    Advantages are that it's cleaner and separates out some things which
    perhaps shouldn't be mixed anyway. Disadvantage is...well...a fair
    amount of code churn. It would also require chrdev-specific wrappers
    to map straight file_operations calls in the VFS to the new
    callbacks.

    3: Provide a new form of cdev_add() which lets the driver indicate
    that the BKL is not needed on open (or anything else?). At a
    minimum, it could just be a new parameter on cdev_add which has a
    value of zero or FIXME_I_STILL_NEED_BKL. Still some churn but easier
    to script and smaller because a lot of drivers are still using
    register_chrdev() - something else worth fixing.

    A more involved form might provide a new chardev_add() which takes
    the new char_dev_ops structure too. Mapping between new and old
    operations vectors would be done internally to avoid breaking older
    drivers before they can be fixed.

    4: Just find every char dev open() function and shove in lock_kernel()
    calls, then remove the call from chrdev_open(). The disadvantage
    here is that, beyond lots of work and churn, there's no way to know
    which ones you missed.

    I kind of like the combination of 2 and 3, done in such a way that
    there's no "every driver must change" flag day. This could be an
    interesting project, even... Thoughts?

    jon


    \
     
     \ /
      Last update: 2008-05-14 23:47    [W:0.021 / U:1.588 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site