From owner-freebsd-hackers Fri Jul 5 1:37:44 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6913237B401 for ; Fri, 5 Jul 2002 01:37:41 -0700 (PDT) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 04BCE43E31 for ; Fri, 5 Jul 2002 01:37:41 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.12.4/8.12.4) with ESMTP id g658beAU026797; Fri, 5 Jul 2002 01:37:40 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.12.4/8.12.4/Submit) id g658bewg026794; Fri, 5 Jul 2002 01:37:40 -0700 (PDT) (envelope-from dillon) Date: Fri, 5 Jul 2002 01:37:40 -0700 (PDT) From: Matthew Dillon Message-Id: <200207050837.g658bewg026794@apollo.backplane.com> To: Terry Lambert Cc: Richard Sharpe , freebsd-hackers@FreeBSD.ORG Subject: Re: Adding readdir entries to the name cache ... References: <3D2504DC.36D046D7@mindspring.com> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG : :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