lkml.org 
[lkml]   [2004]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:06    [from the cache]
©2003-2011 Jasper Spaans