[lkml]   [2004]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] remove the BKL (Big Kernel Lock), this time for real
    On Wed, 15 Sep 2004, Ingo Molnar wrote:
    >> the attached patch is a new approach to get rid of Linux's Big Kernel
    >> Lock as we know it today.
    On Wed, Sep 15, 2004 at 08:40:55AM -0700, Linus Torvalds wrote:
    > I really think this is wrong.
    > Maybe not from a conceptual standpoint, but that implementation with the
    > scheduler doing "reaquire_kernel_lock()" and doing a down() there is just
    > wrong, wrong, wrong.
    > If we're going to do a down() and block immediately after being scheduled,
    > I don't think we should have been picked in the first place.

    Well, I'm more concerned that the users all need to be swept anyway.
    This could make sense to do anyway, but the sweeps IMHO are necessary
    because the users almost universally are those that haven't been taught
    to do any locking yet, stale and crusty code that needs porting, or
    things where the locking hasn't quite been debugged or straightened out.

    One thing I like is that this eliminates the implicit dropping on sleep
    as a source of bugs (e.g. it was recently pointed out to me that setfl()
    uses the BKL to protect ->f_flags in a codepath spanning a sleeping
    call to ->fasync()), where the semaphore may be retained while sleeping.
    I originally wanted to make sleeping under the BKL illegal and sweep
    users to repair when it is, but maybe that's unrealistic, particularly
    considering that the sum of my BKL sweeps to date are one removal from
    procfs "protecting" its access of nr_threads.

    -- wli
    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 14:06    [from the cache]
    ©2003-2014 Jasper Spaans. hosted at Digital Ocean