[PATCH][RFC] slub: increasing order reduces memory usage of somekey caches

From: Richard Kennedy
Date: Wed Jul 16 2008 - 08:29:45 EST


This test patch increases the order of those caches that will gain an
extra object per slab. In particular on 64 bit this effects dentry &

On a freshly booted box after a kernel compile (make clean;make) there
is significant savings in both dentry & radix_tree_node

on my amd64 3 gb ram desktop typical numbers :-

[kernel,objects,pages/slab,slabs,total pages,diff]
2.6.26 33922,2,2423 4846
+patch 33541,4,1165 4660,-186
2.6.26 82136,1,4323 4323
+patch 79482,2,2038 4076,-247
the extra dentries would use 136 pages but that still leaves a saving of
111 pages.

I see some improvement in iozone write/rewrite numbers particularly
apparent at the beginning of a run (I guess when there are no dirty
pages ?).

I've also run this patch on my old laptop( Pentuim M 384Mb ram) & it
works with no problems. After a kernel make there's not much difference
in the used memory but I think I'm seeing a improvement in the elapsed
time. 35 minutes -> 33 minutes. However I've not run this enough times
to tell if this is just luck or noise!

I've been running this on my desktop for several weeks without any

Can anyone suggest any other tests that would be useful to run?
& Is there any way to measure what impact this is having on

Patch against 2.6.26 git.


diff --git a/mm/slub.c b/mm/slub.c
index 315c392..c365b04 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -2301,6 +2301,14 @@ static int calculate_sizes(struct kmem_cache *s, int forced_order)
if (order < 0)
return 0;

+ if (order < slub_max_order ) {
+ unsigned long waste = (PAGE_SIZE << order) % size;
+ if ( waste *2 >= size ) {
+ order++;
+ printk ( KERN_INFO "SLUB: increasing order %s->[%d] [%ld]\n",s->name,order,size);
+ }
+ }
s->allocflags = 0;
if (order)
s->allocflags |= __GFP_COMP;

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/