lkml.org 
[lkml]   [2000]   [Aug]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] getting rid of the Big Kernel Spinlock, 2.4.0-test7


On Mon, 28 Aug 2000, Ingo Molnar wrote:

>
> On Mon, 28 Aug 2000, Alexander Viro wrote:
>
> > Umm... I would not do that. Reason: right now BKL can be acquired
> > while we are holding a spinlock. It's a bad idea, but it's possible.
>
> hm, shouldnt we fix those places? It sounds extremely dangerous to get the
> BKL with a spinlock held.

Probably... ISTR that there was a long-living spinlock somewhere in mm/*.c,
but you are more familiar with that area...

> > With your change it becomes deadly. [...]
>
> agreed, i missed that. Is there any core kernel code that does this? [the
> VFS? :-)]

I can't think of any places where we actually did that, but... it's a
pretty weak warranty ;-/ I've seen a lot of amazingly dumb things
happening and "nobody sane would do that" doesn't replace the analysis -
there's always somebody who wanted to be smart.

VFS _generally_ releases the spinlocks before calling methods (and rules
are described in Documentation/filesystems/Locking), so I think that it's
OK (very easy to verify, anyway), but VM can be scarier and I don't want
even think about drivers... Network stuff seems to be relatively BKL-free.
Architecture-dependent stuff... Hell knows.

> > Another reason: currently BKL can be taken in the middle of operations
> > on per-CPU data. It will not block, so nothing will get that CPU while
> > we are in lock_kernel(). Not true with your patch.
>
> oops, another thinko indeed. Sigh. Are there any prominent examples of
> this? I think we want to fix these.

We probably want, but that will require catching them. It should be easier
now (in almost all cases we have a chance to block very soon after the
lock_kernel(), so areas to look into shouldn't be that large), but I'm not
too happy about making the change without doing their analysis - it will
be needed anyway and doing it now over the whole tree would be easier than
doing it piece-wise later.

Essentially, you are adding tons of scheduling points all over the tree
and it's not a thing to make blindly...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.044 / U:4.672 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site