Ok. During the last days I tested all single shift _hashfn's from (>>2)
to (>>13) and according to these tests the winner is (>>6):
#define _hashfn(dev,block) \
(((unsigned)((HASHDEV(dev)+block)+(block>>6))) & bh_hash_mask)
>> At the moment the buffer cache doesn't like to grow much.
>it totally depends on the workload. i can get it to grow pretty large.
Of course, e.g. 'dd' and 'e2fsck' can grow the buffer cache to use
almost all of the available memory, but these are quite boring tests.
dd is happy with almost any _hashfn.
One of my current benchmarks is 'du > /dev/null' in a large directory
tree so that it still fits into the memory:
du $BENCHDIR; sync; time du $BENCHDIR > /dev/null
This way mostly the raw buffer cache performance is tested (with a
cachesize of >60% of the entire RAM). According to this benchmark a
mean bucketsize (MB) of 8 is about as fast as a MB of 1. A MB of 16 is
much slower (about 6%). Since the benchmark uses > 60% of the entire
RAM I think even the biggest buffer cache should be happy with MB=4 and
a MB of 2 should be plenty.
Peter
--
_ x ___
/ \_/_\_ /,--' p.steiner@t-online.de (Peter Steiner)
\/>'~~~~//
\_____/ signature V0.2 alpha
-
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/