forked from luck/tmp_suning_uos_patched
[PATCH] Sanely size hash tables when using large base pages
At the moment the inode/dentry cache hash tables (common by way of alloc_large_system_hash()) are incorrectly sized by their respective detection logic when we attempt to use large base pages on systems with little memory. This results in odd behaviour when using a 64kB PAGE_SIZE, such as: Dentry cache hash table entries: 8192 (order: -1, 32768 bytes) Inode-cache hash table entries: 4096 (order: -2, 16384 bytes) The mount cache hash table is seemingly the only one that gets this right by directly taking PAGE_SIZE in to account. The following patch attempts to catch the bogus values and round it up to at least 0-order. Signed-off-by: Paul Mundt <lethal@linux-sh.org> Signed-off-by: Andrew Morton <akpm@osdl.org> Signed-off-by: Linus Torvalds <torvalds@osdl.org>
This commit is contained in:
parent
dd0ec16fa6
commit
9ab37b8f21
@ -3321,6 +3321,10 @@ void *__init alloc_large_system_hash(const char *tablename,
|
||||
numentries >>= (scale - PAGE_SHIFT);
|
||||
else
|
||||
numentries <<= (PAGE_SHIFT - scale);
|
||||
|
||||
/* Make sure we've got at least a 0-order allocation.. */
|
||||
if (unlikely((numentries * bucketsize) < PAGE_SIZE))
|
||||
numentries = PAGE_SIZE / bucketsize;
|
||||
}
|
||||
numentries = roundup_pow_of_two(numentries);
|
||||
|
||||
|
Loading…
Reference in New Issue
Block a user