Messages in this thread | | | Date | Mon, 14 Jun 1999 12:18:11 -0400 (EDT) | From | Chuck Lever <> | Subject | Re: [patch] 2.2.9_andrea-VM1.gz |
| |
On Mon, 14 Jun 1999, Peter Steiner wrote: > >as much as i like the multiplicative hash function, i think Linux should > >go with Peter's shift-add function for these reasons: > > 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)
try this for me:
(block) + (block >> hash_bits) + (block >> hash_bits * 2)
where hash_bits is computed the same way as it is computed for other functions like the page cache hash. the "* 2" shift will be zero for all but the largest disks.
> >> 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.
the reason the buffer cache size is probably not important is because the buffer, these days anyway, contains mostly data that is waiting to be written out. data that is cached for reading is stored in the page cache, so allowing that to grow is preferred.
what may affect system performance during memory shortages is how the inode and dentry caches are pruned. i've noticed that most dentries are on the unused list, which grows to be a significant number during any decent system load.
- 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/
| |