On Mon, 9 Jul 2007, 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?
> Because even having 1024 caches wouldn't consume a terrible amount of
> memory and I bet it would result in aggregate savings.
I have tried any number of approaches without too much success. Even one
slab cache for every 8 bytes. This creates additional admin overhead
through more control structure (that is pretty minimal but nevertheless
exists)
The main issue is that kmallocs of different size must use different
pages. If one allocates one 64 byte item and one 256 byte item and both 64
byte and 256 byte are empty then SLAB/SLUB will have to allocate 2 pages.
SLUB can fit them into one. This is basically only relevant early after
boot. The advantage goes away as the system starts to work and as more
objects are allocated in the slabs but the power-of-two slab will always
have to extend its size in page size chunks which leads to some overhead
that SLOB can avoid by placing entities of multiple size in one slab.
The tradeoff in SLOB is that is cannot be an O(1) allocator because it
has to manage these variable sized objects by traversing the lists.
I think the advantage that SLOB generates here is pretty minimal and is
easily offset by the problems of maintaining SLOB.
> Of course, a scheme which creates kmalloc caches on-demand would be better,
> but that would kill our compile-time cache selection, I suspect.
SLUB creates kmalloc caches on-demand for DMA caches already. But then we
are not allowing compile time cache selection for DMA caches.
-
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/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
