Date: Fri, 5 Jul 2002 01:37:40 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Terry Lambert <tlambert2@mindspring.com> Cc: Richard Sharpe <rsharpe@ns.aus.com>, freebsd-hackers@FreeBSD.ORG Subject: Re: Adding readdir entries to the name cache ... Message-ID: <200207050837.g658bewg026794@apollo.backplane.com> References: <Pine.LNX.4.33.0207051104570.2925-100000@ns.aus.com> <3D2504DC.36D046D7@mindspring.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:
: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.
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.
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.
-Matt
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?200207050837.g658bewg026794>