Re: [PATCH] shrink hash sizes on small machines, take 2

[Marcelo Tosatti <marcelo.tosatti@cyclades.com>]

On Sat, Apr 10, 2004 at 06:27:07PM -0500, Matt Mackall wrote:
> The following attempts to cleanly address the low end of the problem,
> something like my calc_hash_order or Marcelo's approach should be used
> to attack the upper end of the problem.
> 
> 8<
> 
> Shrink hashes on small systems
> 
> Base hash sizes on available memory rather than total memory. An
> additional 50% above current used memory is considered reserved for
> the purposes of hash sizing to compensate for the hashes themselves
> and the remainder of kernel and userspace initialization.

Hi Matt, 

As far as I remember from my tests booting with 8MB yields 0-order (one page) 
dentry/inode hash tables, and 16MB yields 
1-order dentry/0-order inode hash. 

So we can't go lower than 1 page on <8MB anyway (and we dont). What 
is the problem you are seeing ?

Your patch changes 16MB to 0-order dentry hashtable?

On the higher end, we still need to figure out if the "huge"
hash tables (1MB dentry/512K inode on 4GB box, upto 8MB hash dentry 
on 16GB box) are really worth it. 

Arjan seems to be clipping the dentry to 128K on RH's kernels. 
I couldnt find much of a difference on dbench performance from 1MB to 512K 
or 128K dhash. Someone willing to help with SDET or different tests?

Thanks!