Date: Fri, 05 Jul 2002 04:57:27 -0700 From: Terry Lambert <tlambert2@mindspring.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Richard Sharpe <rsharpe@ns.aus.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: Adding readdir entries to the name cache ... Message-ID: <3D2589A7.BB02359A@mindspring.com> References: <Pine.LNX.4.33.0207051104570.2925-100000@ns.aus.com> <3D2504DC.36D046D7@mindspring.com> <200207050837.g658bewg026794@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Matthew Dillon wrote: > :Richard Sharpe wrote: > :> I am interested in hearing opinions on whether or not it is useful to > :> preload entries into the name cache that are obtained with > :> readdir/getdirentries/getdents. > : > :It depends. In a past life at another company, we were able to get a > :30%+ performance improvement simply by doing this type of caching. > :The system where the cacheing was being done, though, faulted the > :inodes in asynchornously. > :... > > Hmm. I will note that we already get most of these advantages > from UFS_DIRHASH and DIRPREF. > > In regards to going one step further and preloading the stat > (inode) information... well, I am quite certain that you could > get improvements with microbenchmarks but the problem is that > it could blow the inode cache out of the water and really screw > up performance in a heavily loaded general purpose system. That's > the problem you wind up with when you try to do speculative heavy-weight > caching vs something like UFS_DIRHASH which does speculative light-weight > caching. I specifically limited it to uses with high directory locality, and high locality in general. The case in question was the NetWare for UNIX 4.x product. The "microbenchmark" in question was was Netbench, which is based on recorded data from actual networks at Fortune 500 companies, and repeating the operations that generated the data, in the order it was generated, in the first place. > You also have to keep in mind that while doing potentially discontinuous > read-aheads may help certain microbenchmarks, the extra seeks might > cause a massive loss of performance for other cases. I think the > issue is applicable when attempting to issue read-aheads on the inodes > underlying a directory scan. I can practically guarantee you a performance improvement on any file server from which DOS or Windows executables are run, simply by preferentially caching the first 9K of the image, as the loader and page management, over time, return again and again to read headers and other information from there. 8-). > Remember that the disk drive itself will cache data with locality > of reference, and this covers most of what we want to accomplish > (with dirpref's improved layout) without having to get fancy. Now *those* numbers were the result of microbenchmarks... 8-). -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D2589A7.BB02359A>