diff options
| author | Zhang Yanmin <yanmin.zhang@linux.intel.com> | 2009-02-12 18:00:17 +0200 |
|---|---|---|
| committer | Pekka Enberg <penberg@cs.helsinki.fi> | 2009-02-20 12:26:12 +0200 |
| commit | e8120ff1ffc51102ead1f4c98a3fd5d26fefc722 (patch) | |
| tree | 3cdadf0dc36df4a34f5ef30a788ef62d3a601de8 /mm | |
| parent | 51735a7ca67531267a27b57e5fe20f7815192f9c (diff) | |
SLUB: Fix default slab order for big object sizes
The default order of kmalloc-8192 on 2*4 stoakley is an issue of
calculate_order.
slab_size order name
-------------------------------------------------
4096 3 sgpool-128
8192 2 kmalloc-8192
16384 3 kmalloc-16384
kmalloc-8192's default order is smaller than sgpool-128's.
On 4*4 tigerton machine, a similiar issue appears on another kmem_cache.
Function calculate_order uses 'min_objects /= 2;' to shrink. Plus size
calculation/checking in slab_order, sometimes above issue appear.
Below patch against 2.6.29-rc2 fixes it.
I checked the default orders of all kmem_cache and they don't become
smaller than before. So the patch wouldn't hurt performance.
Signed-off-by Zhang Yanmin <yanmin.zhang@linux.intel.com>
Signed-off-by: Pekka Enberg <penberg@cs.helsinki.fi>
Diffstat (limited to 'mm')
| -rw-r--r-- | mm/slub.c | 6 |
1 files changed, 5 insertions, 1 deletions
diff --git a/mm/slub.c b/mm/slub.c index 5a5e7f5bf79..c01a7a3001d 100644 --- a/mm/slub.c +++ b/mm/slub.c @@ -1844,6 +1844,7 @@ static inline int calculate_order(int size) int order; int min_objects; int fraction; + int max_objects; /* * Attempt to find best configuration for a slab. This @@ -1856,6 +1857,9 @@ static inline int calculate_order(int size) min_objects = slub_min_objects; if (!min_objects) min_objects = 4 * (fls(nr_cpu_ids) + 1); + max_objects = (PAGE_SIZE << slub_max_order)/size; + min_objects = min(min_objects, max_objects); + while (min_objects > 1) { fraction = 16; while (fraction >= 4) { @@ -1865,7 +1869,7 @@ static inline int calculate_order(int size) return order; fraction /= 2; } - min_objects /= 2; + min_objects --; } /* |