Date: Tue, 17 Oct 2006 12:28:57 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Chuck Lever <chucklever@gmail.com> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, mjacob@FreeBSD.org, cvs-all@FreeBSD.org, Kris Kennaway <kris@obsecurity.org> Subject: Re: cvs commit: src/sys/nfsclient nfs_vnops.c Message-ID: <20061017113943.C67620@delplex.bde.org> In-Reply-To: <76bd70e30610160620x67e5d3a5j938c26744d0b9759@mail.gmail.com> References: <200610140725.k9E7PC37008454@repoman.freebsd.org> <20061014231502.GA38708@rink.nu> <20061015105809.M59123@delplex.bde.org> <20061015051044.GA42764@xor.obsecurity.org> <20061014222221.H97880@ns1.feral.com> <20061014222437.N4701@ns1.feral.com> <20061015153454.G59979@delplex.bde.org> <76bd70e30610150837w61689cf6ya2499d100a15c3e8@mail.gmail.com> <20061016164122.S63585@delplex.bde.org> <76bd70e30610160620x67e5d3a5j938c26744d0b9759@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 16 Oct 2006, Chuck Lever wrote: > On 10/16/06, Bruce Evans <bde@zeta.org.au> wrote: >> On Sun, 15 Oct 2006, Chuck Lever wrote: >>> [An independent imeout for the access cache isn't useful.] >> >> I'll try removing the special support for the access cache timeout in >> rc.conf first. > > OK. I can review patches if you think that would help, but I can't > contribute code at the moment because of IP issues at my current > employer. Hopefully that will change soon. Thanks. Removing it in rc.conf won't require review :-). >> > Again, I'm not sure why it is necessary to clear the attribute cache, >> > when simply verifying that the file object remains the same is all >> > that is necessary. >> >> An RPC is required to tell if the file changed. FreeBSD just always >> uses a Getattr RPC (NFSV3ACCESS_ALL) for this in the v3 case. Getting >> all the attributes at once is supposed to be an optimization. > > What I'm getting at here is that clearing the cache and verifying the > cache are different things. Yes, both still require at least one RPC > on the wire. But clearing then replacing the attribute information is > actually fairly client-CPU-expensive compared to verifying, especially > since it is done so often. We're spoiled by CPUs being too fast relative to i/o. > Another thing to consider is that a LOOKUP is usually more expensive > for servers than a GETATTR. If your client has already cached lookup > results for the file to be opened, you can get away with a GETATTR on > the parent directory to verify that it has not changed, and that will > almost always be faster than doing a full LOOKUP. FreeBSD's client is doing not very good things for Lookup too. It is missing caching of negative lookups. make(1) likes to do a lot of negative lookups... NetBSD fixed this in 1997, sigh. I changed my quick fix to not flush the attribute cache in nfs_close() (instead of not flushing it in nfs_open()). This increased the number of Access RPCs by about 5000, so all the RPC counts are almost exactly the same as in RELENG_4 and made -current about 2% slower than RELENG_4 instead of only 1% slower. The current RPC counts for rebuilds after "make clean cleandepend" are: make depend: Lookup Read Write Access Getattr Other Total 14203 548 599 21561 454 97 37462 make: Lookup Read Write Create Access Fsstat Other Total 19543 2410 5353 442 24241 1742 14 53745 Other statistics show that the kernel build involves about 1700 positive lookups and that the name cache effectiveness for nfs is only about 80%. We should be doing only about 2000 Lookups starting from scratch, and at most about 500 (about the number of object files deleted by "make clean") for rebuilds. "make -n" when there is nothing to do also has a name cache hit rate of about 80%. Turning of my hack fix for lost vfs caching of dotdot gives 59000+ Lookups instead of only 19000+, but doesn't affect the hit rate much. Reducing the Access count will be more interesting when the Lookup count is reduced to < 2000. The above access count of 24241 is almost exactly the same as the number of #include files, so it cannot be reduced much without losing cto consistency, but without cto consistency, since almost all opens are for the same few hundred include files, the Access count can probably be reduced by a factor of 10 too. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20061017113943.C67620>