On Wed, 27 Oct 1999 16:29:02 +0100 (BST), Tigran Aivazian
<tigran@sco.COM> said:
> Yes, but I try not to make use of the big kernel lock assumption as I
> would *not* like to hinder the process of getting rid of big kernel lock
> and ensuring "fine-grained SMP locking".
That's fine too --- the point is that it is up to the filesystem. If
you want to drop the lock for the duration of the allocation, you are
free to do so. If you need more locking, you are free to add it. In
this specific case, there is nothing in the VFS which forces you to
use the superblock lock --- the filesystem's internal locking is
entirely up to you.
> Another case, where I really don't like the way Linux relies on big kernel
> lock is registering/unregistering filesystems. Currently it is only done
> either in initialization context or from module_init/cleanup which means
> we either don't need a lock or have a big kernel lock respectively. I
> would have preferred to see file_systems protected by a read-write lock
> whereby register/unregister take a write and all others take a
> read.
That could be done, but so much of the filesystem code relies on the
big lock right now that you'd want to deal with that first ---
registration is a relatively minor issue.
--Stephen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/