On Fri, 8 Jun 2001, Bryan Henderson wrote:
> introduced, it was not practical to update every filesystem driver, so the
> Big Kernel Lock (BKL) was added to give those drivers the uninterrupted
> access they (may) expect. You may surmise that a "lookup" routine doesn't
> need such uninterrupted access, but you can never really assume that.
Now, now. BKL _is_ worth the removal. The thing being, "oh, we just take
BKL, so we don't have to worry about SMP races" is wrong attitude. In practice.
For every SMP race there's a UP one lurking nearby.
If code is race-free on single-processor and reasonably clean making it
SMP-safe is easy.
> I think an individual filesystem driver that is specifically designed to
> do the fine-grained locking necessary to tolerate multiple CPUs can just
> release the BKL and avoid any bottleneck.
I doubt that BKL is a real bottleneck here, but... Making the filesystem
code SMP-safe is a Good Thing(tm). Usually you either do it with a couple
of trivial changes (and then you can decide if you need to replace BKL with
extra spinlocks to protect the critical areas - it's a separate question)
_or_ you discover a crapload of races that had been there since times
immemorial. On single-processor boxen.
IOW, "specifically designed" is a myth. Writing SMP-safe code doesn't require
special design - it's more or less the same as robust single-processor code.
However, actual removal of BKL from there is a 2.5 project. ->lookup() is
a method present in a lot of filesystems (heck, in all of them), so
changing that API is for -CURRENT, not -STABLE.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
