Messages in this thread | | | Date | Thu, 15 Apr 2004 12:16:36 -0300 | From | Marcelo Tosatti <> | Subject | Re: [PATCH] shrink hash sizes on small machines, take 2 |
| |
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! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |