diff options
| author | Paul Mundt <lethal@linux-sh.org> | 2007-01-05 16:36:30 -0800 |
|---|---|---|
| committer | Linus Torvalds <torvalds@woody.osdl.org> | 2007-01-05 23:55:23 -0800 |
| commit | 9ab37b8f21b4dfe256d736c13738d20c88a1f3ad (patch) | |
| tree | 11b7b33b1e88ce19175492f25cfc71add2b3dcd6 /mm | |
| parent | dd0ec16fa6cf2498b831663a543e1b67fce6e155 (diff) | |
| download | talos-op-linux-9ab37b8f21b4dfe256d736c13738d20c88a1f3ad.tar.gz talos-op-linux-9ab37b8f21b4dfe256d736c13738d20c88a1f3ad.zip | |
[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>
Diffstat (limited to 'mm')
| -rw-r--r-- | mm/page_alloc.c | 4 |
1 files changed, 4 insertions, 0 deletions
diff --git a/mm/page_alloc.c b/mm/page_alloc.c index 8c1a116875bc..4a9a83fc1b39 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -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); |
