lkml.org 
[lkml]   [1999]   [Jun]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.093 / U:0.120 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site