Messages in this thread | | | Date | Thu, 28 Oct 1999 12:22:40 -0400 | From | "Theodore Y. Ts'o" <> | Subject | Re: lock/unlock_super and inode bitmaps. |
| |
Date: Thu, 28 Oct 1999 07:52:12 +0100 (BST) From: Tigran Aivazian <tigran@sco.COM>
I disagree with your points and here is why. The reason why is not because of registering/unregistering is done often but rather implicit - because otherwise things like sys_sysfs() (and possibly others) wouldn't need to take a big kernel lock (because underlying routine fs_index() which manipulate file_systems would just take a read lock).
So, what I was proposing would reduce the number of other things taking big kernel lock and thus affecting yet other, completely unrelated to file_systems things.
It's important to look at what actually *uses* file_systems to see if it really is going to result in a lot of taking of the Big Lock. A quick check shows that file_systems is used by mount, sys_sysfs (which is this wierd System V compatibility system call -- not used much), /proc/filesystems, and by registering and unregistering filesystems.
I may be missing one or two, but I'm pretty sure that nothing performance critical actually touches file_systems. If that's the case, why add the extra lock? Each lock means added complexity, and keeping complexioty down is a good thing.
Larry McVoy has a theory that once you have too many locks, it becomes too complicated for humans to keep track of what individual locks do, so in order to be safe, they just "add another lock", which makes the locking discpline even more complex, and takes the OS down a positive feedback loop that makes the whole thing much less performant and much more complex. He calls this phenomenom "falling off the locking cliff", I believe it's a good insight.
Each new lock should be carefully scrutinized and asked to justify its existence; if we need it, fine let's add it. Otherwise, forbearance may be the better part of valor.
- Ted
- 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/
| |