Date: Sun, 27 Apr 1997 10:42:13 +0900 (JST) From: Michael Hancock <michaelh@cet.co.jp> To: Terry Lambert <terry@lambert.org> Cc: Bruce Evans <bde@zeta.org.au>, msmith@atrad.adelaide.edu.au, hackers@hub.freebsd.org Subject: Re: namei & hash functions Message-ID: <Pine.SV4.3.95.970427102525.25227A-100000@parkplace.cet.co.jp> In-Reply-To: <199704261953.MAA07467@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 26 Apr 1997, Terry Lambert wrote: > Knuth is very clear in "Sorting and Searching" that primacy helps to > disperse the bucket hits; however, once they are dispersed, it's not > a big deal what intelligence caused the dispersion, so long as you > don't get unbalanced hash chain lengths. I don't know if the shift > by 5 version is really inferior; it depends on whether or not it > causes disproportionate hash chain length between buckets, doesn't it? I was playing around with the strength of the intelligence that made the dispersion. I'm a little weak on Intel assembler so I wasn't sure how much faster a integer mult was over an integer divide. Anyway, I think phk's suggestion made earlier on the fs list makes sense. He's saying that there are a lot of stale entries sitting in the buckets so a larger hashsize would reduce the time throwing out stale entries that get in the way during the search aside from the obvious performance enhancement of a larger hash table. He's working on another approach that simplifies keeping the name cache and active vnode in sync by hanging the name cache of the directory vnode. A lot of us are saying that operations like article list request against innd would suffer with this approach. Mike Hancock
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.SV4.3.95.970427102525.25227A-100000>