--qMm9M+Fa2AknHoGS
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Tue, May 25, 2004 at 09:59:18PM +0900, YAMAMOTO Takashi wrote:
> hi,
>=20
> i'd like to add an additional "lkflag" argument to VFS_VGET
> and VFS_FHTOVP so that nfsd won't try to acquire exclusive lock
> unnecessarily.
>=20
> the attached diff contains only ffs and nfs.
> if no one objects, i'll do the rest of filesystems and check them in.

Please don't. I consider all current uses of LK_SHARED in the vnode code=20
to be bugs, and I'd rather not see more uses go in. :-)

All of our file systems were designed assuming that vnode locks were=20
exclusive; if you had the lock you could change anything w/o concern.=20
Also, if you ever had to drop a lock then reaquire it (say either you=20
wanted to grab a different lock w/o deadlock, or you had to sleep on=20
something else), you always should reaquire an LK_EXCLUSIVE lock.

While not the most concurrent, our VOP interface was pretty MP-safe. Since
all the locks were exclusive, you could have as many threads wandering
around in the vnode system, on as many CPUs as you wanted. So once all the
systems below the VOP layer (the buffer cache and the vm cache and the
disk drivers) were MP-safe, it would be reasonable to start letting some
file operations past the big-lock. Since the buffer cache and vm cache=20
have been MP-ified, we are actually close to that. The bottom-half of the=
=20
kernel is the only remaining issue.

However as we start using LK_SHARED, the only thing that is keeping the
VOP interface safe is our use of big-lock in the kernel. That's a step
backwards for SMP, in my opinion.

Before we start letting certain vnode users grab LK_SHARED locks, we=20
should document what VOP calls can take shared locks and audit our file=20
systems to see that they will work correctly with them. After we know we=20
can correctly use LK_SHARED locks, then I think it's fine to start using=20
them.

As to your patch, I certainly don't mind you making it easier to use=20
LK_SHARED in the future. I'd be very happy with the change if you just=20
didn't actually use "LK_SHARED" as a flag. Use LK_EXCLUSIVE and add fat=20
comments saying 'This should use LK_SHARED as soon as ...'.

Take care,

Bill

--qMm9M+Fa2AknHoGS
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (NetBSD)

iD8DBQFAs3fuWz+3JHUci9cRAi/VAJ9AEYqm38al9rn5w8EJf2RrB1glWQCggG4N
ZXLploJNzhs0xll6YoxWCfw=
=Q+mA
-----END PGP SIGNATURE-----

--qMm9M+Fa2AknHoGS--