shrink hash sizes on small machines, take 2
PATCH 1/1 shrink hash sizes on small machines, take 2
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.
fs/dcache.c +13 -4
@@ -28,6 +28,7 @@#include <asm/uaccess.h> #include <linux/security.h> #include <linux/seqlock.h> +#include <linux/swap.h> #define DCACHE_PARANOIA 1/* #define DCACHE_DEBUG 1 */
@@ -1619,13 +1620,21 @@void __init vfs_caches_init (unsigned long mempages) { - names_cachep =kmem_cache_create ("names_cache" , -PATH_MAX ,0 , +unsigned long reserve; + +/* Base hash sizes on available memory, with a reserve equal to +150% of current kernel size */ + + reserve = (mempages -nr_free_pages ()) *3 /2 ; + mempages -= reserve; + + names_cachep =kmem_cache_create ("names_cache" , +PATH_MAX ,0 ,SLAB_HWCACHE_ALIGN ,NULL ,NULL );if (!names_cachep)panic ("Cannot create names SLAB cache" ); - filp_cachep =kmem_cache_create ("filp" , + filp_cachep =kmem_cache_create ("filp" ,sizeof (struct file ),0 ,SLAB_HWCACHE_ALIGN , filp_ctor, filp_dtor);if (!filp_cachep)
@@ -1633,7 +1642,7 @@dcache_init (mempages);inode_init (mempages); -files_init (mempages); +files_init (mempages);mnt_init (mempages);bdev_cache_init ();chrdev_init ();
Signature · 1 line
Matt Mackall : http://www.selenic.com : Linux development and consulting
Quoted 4 lines · Matt Mackall
The following attempts to cleanly address the low end of the problem, something like my
calc_hash_orderor Marcelo's approach should be used to attack the upper end of the problem.
Quoted 8 lines
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!