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 /include/linux/slub_def.h | |
| parent | 51735a7ca67531267a27b57e5fe20f7815192f9c (diff) | |
| download | talos-op-linux-e8120ff1ffc51102ead1f4c98a3fd5d26fefc722.tar.gz talos-op-linux-e8120ff1ffc51102ead1f4c98a3fd5d26fefc722.zip | |
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 'include/linux/slub_def.h')
0 files changed, 0 insertions, 0 deletions
