On Mon, Jul 09, 2007 at 09:51:16AM -0700, Andrew Morton wrote: > On Mon, 9 Jul 2007 09:06:46 -0700 (PDT) Christoph Lameter <[EMAIL PROTECTED]> > wrote: > > > But yes the power of > > two caches are a necessary design feature of SLAB/SLUB that allows O(1) > > operations of kmalloc slabs which in turns causes memory wastage because > > of rounding of the alloc to the next power of two. > > I've frequently wondered why we don't just create more caches for kmalloc: > make it denser than each-power-of-2-plus-a-few-others-in-between. > > I assume the tradeoff here is better packing versus having a ridiculous > number of caches. Is there any other cost?
It magnifies the fragmentation problem. SLAB (and SLUB) makes the optimistic assumption that objects of the same type/size have similar lifetimes. But for some objects, it's not uncommon to do many temporary allocations but have some objects with indefinite lifespans. dcache is a very frequently encountered example, but there's no reason we couldn't see it with sockets and many other object types. Every new arena introduces further opportunity for this sort of fragmentation. If we had, say, separate pools for 48 byte and 64 byte objects, an unfortunate usage pattern for 48-byte kmallocs could DoS requests for 64 byte objects that would work just fine if they both came out of the same pool. If we have 10 pools with long-lived objects, we're much worse off than if we had 1 or 2. -- Mathematics is the supreme nostalgia of our time. - 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/