On Wed, 2005-11-30 at 08:49 -0800, Badari Pulavarty wrote: > On Wed, 2005-11-30 at 09:02 -0500, Ian Kent wrote: > > On Tue, 29 Nov 2005, William H. Taber wrote: > > > > > Ian Kent wrote: > > > > We'll need to do an analysis of all callers of the revalidate method. > > > You are right. Searching through the sources, it would appear that I > > > missed fixing autofs and devfs. Everyone else just defines a revalidate > > > routine but doesn't call one. You may find devfs to be interesting > > > because they have code to determine whether they need to release the > > > i_sem lock or not. I am working on an updated patch to include the > > > changes needed for these two modules. > > > > I've looked at devfs before but that bit of code sounds interesting to me. > > > > The other thing that concerns me is that we may be increasing the latency > > of some code paths that need to be really fast. I was thinking that > > perhaps it might be good to try a change more in line with the locking > > used in link_patch_walk (ie. i_sem free revalidate) rather than that used > > in lookup_one_len. My only justification being that lookup is called to > > create stuff where revalidate is called to check stuff. I've been > > poking around and this change looks fairly difficult as well (I seem to > > remember you also looked at this). > > > > Anyway, I'm keen to have a look at your patch. > > Thanks much for your interest and help. > > > > Ian > > > > Again, I am posting Will's latest patch on his behalf. > > Any thoughts on how acceptable are the VFS changes ?
That will slow link_path_walk() for commonly accessed shared directories (/lib, /usr/share,...) down to a crawl. Instead of having lock-free lookups of cached dentries, you are suddenly serialising everybody in the parent directory. Cheers, Trond _______________________________________________ autofs mailing list [email protected] http://linux.kernel.org/mailman/listinfo/autofs
