lkml.org 
[lkml]   [1999]   [Oct]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:54    [W:0.044 / U:0.856 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site