From owner-freebsd-fs Tue Jul 3 10:54: 9 2001 Delivered-To: freebsd-fs@freebsd.org Received: from earth.backplane.com (earth-nat-cw.backplane.com [208.161.114.67]) by hub.freebsd.org (Postfix) with ESMTP id DEF8637B406 for ; Tue, 3 Jul 2001 10:54:05 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.3/8.11.2) id f63Hrnd33021; Tue, 3 Jul 2001 10:53:49 -0700 (PDT) (envelope-from dillon) Date: Tue, 3 Jul 2001 10:53:49 -0700 (PDT) From: Matt Dillon Message-Id: <200107031753.f63Hrnd33021@earth.backplane.com> To: Ian Dowse Cc: freebsd-fs@FreeBSD.ORG, mckusick@mckusick.com Subject: Re: CFR: UFS directory hashing References: <200107020122.aa66571@salmon.maths.tcd.ie> Sender: owner-freebsd-fs@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.org :In message <200106192016.aa70837@salmon.maths.tcd.ie>, Ian Dowse writes: :> :>If there are no objections, I would like to commit the UFS_DIRHASH :>patch in the next few days. The current patch is at : :A few issues cropped up, so I'm holding off committing this for a :while. For two access patterns that are quite common, the use of :UFS_DIRHASH caused a significant reduction in performance, so I'd :like to address these before committing the patch. : :The first issue is the case of sequential lookups on all directory :entries. This case is highly optimised in UFS, but the dirhash code :did not treat it specially. I have added a simple optimisation for :this case, but it needs a bit more work. : :Kirk McKusick ran some filesystem benchmark code with the dirhash :code enabled. He found that if the dirhash memory limit was set :too small relative to the working set of directories, dirhash would :cause a significant performance reduction as compared with the :non-dirhash case. I believe this is caused by a thrashing effect; :if the hash structures are discarded after only a tiny number of :accesses, then the hashing gains are lost by the increased cost of :building the hashes. I think the situation here can be improved by :using something better than LRU for recycling, and by waiting for :a few accesses before going to the trouble of building the hash. : :Ian Hmm. I don't think messing with the recycling algorithm will help. A delayed approach to hashing the directory might work, you could use the directory vnode or the namei cache (associated with the directory itself) to store the statistics or something like that. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-fs" in the body of the message