On Fri, Nov 05, 2004 at 03:56:52PM -0500, Chaskiel M Grundman wrote: > --On Friday, November 05, 2004 15:19:39 -0500 "John S. Bucy" > <[EMAIL PROTECTED]> wrote: > > > > > Our experience with PAG problems has been that when the system goes to > > the wall and runs out of PAGs that the cache manager effectively > > deadlocks. afs_setpag() is protected by the GLOCK and so it seems > > plausible that reducing its use of the GLOCK might be beneficial. It > > seems like it shouldn't be much work to add some finer-grained locking > > here; I'm just not sure what locks I should be using. The afs/lock.h > > ones? > > you can only call ObtainXXXLock or afs_osi_Wait()/afs_osi_Sleep while > holding the GLOCK. The lock functions do not actually contain a mutual > exclusion mechanism - they rely on the GLOCK to provide one. the GLOCK is > automatically released by afs_osi_Wait/afs_osi_Sleep, so I don't think that > is the problem you are having.
I noticed that looking at the code. This may be a dumb question but it seems like this locking scheme will lead to a lot of contention for GLOCK. Is it known how this affects the concurrency of the client? The obvious thing to want to do is have a struct afs_mutex which contains whatever the underlying system gives us. It would probably be a lot of work to change; I guess we'd need to establish that the client is serializing around GLOCK needlessly, first. john _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
