Date: Tue, 3 Jul 2001 10:53:49 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Ian Dowse <iedowse@maths.tcd.ie> Cc: freebsd-fs@FreeBSD.ORG, mckusick@mckusick.com Subject: Re: CFR: UFS directory hashing Message-ID: <200107031753.f63Hrnd33021@earth.backplane.com> References: <200107020122.aa66571@salmon.maths.tcd.ie>
next in thread | previous in thread | raw e-mail | index | archive | help
: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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200107031753.f63Hrnd33021>