Messages in this thread | | | Subject | Re: [PATCH] dentry and inode cache hash algorithm performance changes. | From | Dave Hansen <> | Date | Fri, 07 May 2004 18:03:39 -0700 |
| |
On Fri, 2004-05-07 at 06:04, Jose R. Santos wrote: > On 05/04/04 13:55:10, Andrew Morton wrote: > > > Andrew - Is there any workload you want me to run to show that this hash > > > function is going to be equal or better that the one already provided > > > in Linux? > > > > Not really - it sounds like you've covered it pretty well. Did you try SDET? > > > > It could be that reducing the hash table size will turn pretty much any > > workload into a test of the hash quality. > > Sorry for the late reply... > > Steve Pratt seem to have a SDET setup already and he did me the favor of > running SDET with a reduce dentry entry hash table size. I belive that > his table suggest that less than 3% change is acceptable variability, but > overall he got a 5% better number using the new hash algorith.
It's usually best to keep increasing the number of SDET iterations that you average against, at least until the averages start to become a bit less bouncy. Also, mounting ramfs on /tmp can _really_ help lower its variability, probably because of gcc.
You might be lucky enough to get some consistently good numbers that way.
-- Dave
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |