On Wed, Nov 28, 2001 at 12:31:29AM -0000, David Laight wrote:
> One note about the stats given, is that although the hash lists were
> much more even, the total time for the test was largely unchanged!
> This surely means that either (1) the time spent in this lookup is
> completely insignificant or (2) the cost of the 'new improved hash'
> function completely overwhelms the 'benefit' of reducing the length
> of the hash chains.  In either case the proposed change is of no (real)
> benefit.

That's because I wasn't trying to determine where the other
bottlenecks were; this was a preliminary test.

I saw this code in FreeBSD, read their commit messages detailing how
it made a noticable positive difference for them in certain situations,
and decided to go from there.

It could be that improving the hash will have much greater benefit in
situations where the network pipe is fatter, the nfs server is faster,
and there's a lot more files and directories in active use (i.e,
the virtual server farm at Yahoo?)


What would be *FAR* more useful to this discussion for you to
provide other benchmark results from a variety of different
environments that help to prove the change one way or another. It's
frustrating trying to test and implement fixes and improvements to
NetBSD when people on the mailing list get on their high horse with
academic explanatations about why something won't work and we should
not change, without having some data to back up their assertions.
All this results in is the change not happening because the original
poster is frustrated and gets discouraged, and then (often the
same) people complaining in the future about how other systems (e.g
FreeBSD) are leaps and bounds ahead in various performance stakes.