i think that's artificial -- in real-world situations, we don't
have that kind of control over the hash, and it would "dishonest" to
suggest that this number meant something specific.
> With your patch it get's kind of "shift 11",
> "shift 12" or "shift 10" which is not very descriptive.
agreed.
> Using different
> block sizes makes the results of all current methods bogus anyway.
also agreed.
> Anyway... Chuck, did my last mail reach you? It seems some of my latest
> mails went to nowhere. According to my benchmarks with various hash
> table sizes (1, 2, 4 and 8) a shift value of 6 is about 3-6% faster
> than the '>>bh_hash_bits' hashfn in the raw cache performance (du
> test).
do you have both SCSI and IDE disks of varying sizes? any benchmarks
besides du, like bonnie, or timing a kernel build?
your tests suggest fixing the shift value at 6, instead of using hashbits,
for varying hash table sizes and block sizes?
have you examined the goodness of the page cache hash function?
questions, questions...
- Chuck Lever
-- corporate: <chuckl@netscape.com> personal: <chucklever@netscape.net> or <cel@monkey.org>The Linux Scalability project: http://www.citi.umich.edu/projects/linux-scalability/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/