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 SLOB: (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? Pekka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/