[lkml]   [2007]   [Jul]   [9]   [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
    On Mon, 9 Jul 2007, Andrew Morton wrote:

    > On Mon, 9 Jul 2007 09:06:46 -0700 (PDT) Christoph Lameter <> 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

    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-07-09 19:29    [W:0.030 / U:7.204 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site