[lkml]   [2007]   [Jul]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch 09/10] Remove the SLOB allocator for 2.6.23
Hi Christoph,

On Mon, 9 Jul 2007, Pekka Enberg wrote:
> > I assume with "slab external fragmentation" you mean allocating a
> > whole page for a slab when there are not enough objects to fill the
> > whole thing thus wasting memory? We could try to combat that by
> > packing multiple variable-sized slabs within a single page. Also,
> > adding some non-power-of-two kmalloc caches might help with internal
> > fragmentation.

On Mon, 9 Jul 2007, Christoph Lameter wrote:
> Ther are already non-power-of-two kmalloc caches for 96 and 192 bytes
> sizes.

I know that, but for my setup at least, there seems to be a need for a
non-power of two cache between 512 and 1024. What I am seeing is average
allocation size for kmalloc-512 being around 270-280 which wastes total
of 10 KB of memory due to internal fragmentation. Might be a buggy caller
that can be fixed with its own cache too.

On Mon, 9 Jul 2007, Pekka Enberg wrote:
> > In any case, SLUB needs some serious tuning for smaller machines
> > before we can get rid of SLOB.

On Mon, 9 Jul 2007, Christoph Lameter wrote:
> Switch off CONFIG_SLUB_DEBUG to get memory savings.

Curious, /proc/meminfo immediately after boot shows:

SLUB (debugging enabled):

(none):~# cat /proc/meminfo
MemTotal: 30260 kB
MemFree: 22096 kB

SLUB (debugging disabled):

(none):~# cat /proc/meminfo
MemTotal: 30276 kB
MemFree: 22244 kB


(none):~# cat /proc/meminfo
MemTotal: 30280 kB
MemFree: 22004 kB

That's 92 KB advantage for SLUB with debugging enabled and 240 KB when
debugging is disabled.

Nick, Matt, care to retest SLUB and SLOB for your setups?

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2007-07-10 10:21    [from the cache]
©2003-2014 Jasper Spaans. hosted at Digital Ocean