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/