[lkml]   [2002]   [Jul]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: BKL removal
    I wrote:

    > The problem is, of course, that to responsibly use the BKL, you must
    > fully understand ALL the code that utilizes it, so that you know your
    > new use of it doesn't conflict or interfere with existing code and
    > usage. That's the same problem we have when it DOES show contention --
    > is the problem in the functions which can't grab it (for trying
    > unnecessarily), or in the functions that can (for holding it
    > unnecessarily)?

    Greg responded:

    But the driverfs and USB code do _not_ show contention. Or if they
    do (as Dave pointed out in the driverfs code) it's in a
    non-critical point in the kernel's life (boot time, USB device
    removal, etc.)

    Ok, I think this underscores something I haven't seen clearly stated
    here before. Yes, if you can demonstrate contention, you have a
    problem that needs fixing, and I think few would argue it shouldn't be

    However, I look at this from a supportability point of view as well --
    a lock such as the BKL which is used for multiple reasons by multiple
    subsystems, when it DOES show contention, is harder to fix. People
    trying to fix old code wonder if a particular section really needs the
    BKL, and give up figuring it out because its too hard.

    So while contention can bring a lot of (unwanted) attention to a
    spinlock, including the BKL, I want to see the BKL reduced even if it's
    NOT showing contention, because it makes it easier to debug the cases
    where it IS being used. Unless a developer is relying on the
    release-on-sleep mechanism or the nested-locks-without-deadlock
    mechanism, there's no reason an instance of the BKL can't be replaced
    with another spinlock.

    Arguing that efforts to replace it have indicated we don't know
    how it is really used just supports my point. I don't think anybody
    exists who can claim (or will admit :) that they know why the BKL is
    used everywhere it is. We either need to develop that person (and keep
    them safe from harm!) or make it easier to understand "on the fly".
    I believe that reducing the varied usages, even harmless ones", will
    make it easier to either clearly document the remaining usages or
    to understand it "on the fly".

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:27    [W:0.022 / U:1.352 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site