Messages in this thread | | | Date | Thu, 28 Oct 1999 07:52:12 +0100 (BST) | From | Tigran Aivazian <> | Subject | Re: lock/unlock_super and inode bitmaps. |
| |
Hi Theodore,
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.
Regards, ------ Tigran A. Aivazian | http://www.sco.com Escalations Research Group | tel: +44-(0)1923-813796 Santa Cruz Operation Ltd | http://www.ocston.org/~tigran
On Wed, 27 Oct 1999, Theodore Y. Ts'o wrote:
> Date: Wed, 27 Oct 1999 16:29:02 +0100 (BST) > From: Tigran Aivazian <tigran@sco.COM> > > 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. When > I wanted to do it I hit the obstacle - the way mount_root() walks through > it sleeping on the way (in read_super())... > > Umm... it's not like registering/unregistering filesystems is a very > common activity. If we need to take the Big Lock while we register a > filesystem, it's hardly going to hurt anyone. It's not like this is > done thousands of times a second. :-) > > - 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/
| |