"Bryan Henderson" <[EMAIL PROTECTED]> wrote:
> I think what may have gotten lost in Alexander's detailed reply is the big
> picture on the BKL in VFS. The issue of the BLK protecting ->lookup is
> the same as for every other VFS call:
>
> A whole bunch of filesystem drivers were designed in a time when there
> could be only one CPU, and coupled with a non-preemptive kernel, that
> meant these filesystem drivers could depend on uninterrupted access to
> data structures and filesystems. When the multiple CPU case was
> 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.
>
> 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.
>
If the vfs level code in something like the lookup path was thread safe,
then rather than the grab lock/release lock, do the work, grab lock/release
lock sequence, would it be better to add something to allow the vfs
code to not grab the lock for filesystems which indicate this is a safe
thing to do? Some sort of mask in the superblock would be one way to
do this. That way the lock could be totally avoided, and individual
filesystems which need the BKL could be tackled one at a time. I would
have to rely on Al to say which of the VFS level operations still using
the BKL have the potential to be changed in this way.
Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
