Re: [patch 09/10] Remove the SLOB allocator for 2.6.23

Christoph Lameter wrote:
On Mon, 9 Jul 2007, Nick Piggin wrote:


A reason for retaining slob would be that it has some O(n) memory saving
due to better packing, etc. Indeed that was the reason for merging it in
the first place. If slob no longer retains that advantage (wrt slub) then
we no longer need it.

SLOB contains several significant O(1) and also O(n) memory savings that
are so far impossible-by-design for SLUB. They are: slab external
fragmentation is significantly reduced; kmalloc internal fragmentation is
significantly reduced; order of magnitude smaller kmem_cache data type;
order of magnitude less code...


Well that is only true for kmalloc objects < PAGE_SIZE and to some extend offset by the need to keep per object data in SLUB. 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. SLUB has less wastage
there than SLAB since it can fit power of two object tightly into a slab instead of having to place additional control information there like SLAB.

OK but we're talking about SLOB. And the number that matters is the amount
of memory used, which is higher with SLUB than with SLOB in our tests.


O(n) memory savings? What is that?

Allocate n things and your memory waste is proportional to n (well that's
O(n) waste, so I guess by savings I mean that SLOB's memory saving compared
to SLUB are proportional to n).

--
SUSE Labs, Novell Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages

  • Re: lockdep complaints in slab allocator
    ... We re-enter the slab allocator from the outer edges ... which means you should probably be evaluating SLUB. ... Weren't we going to go with SLQB? ... SLOB: useful for low-end embedded ...
    (Linux-Kernel)
  • Re: [PATCH RT 00/02] SLOB optimizations
    ... >> The old SLOB did the old K&R memory allocations. ... > 16MB of memory, so the linked list walking is pretty well bounded. ... I think this is due to the complexity of the current SLAB. ...
    (Linux-Kernel)
  • Re: [patch] SLQB slab allocator
    ... That's been making SLUB behave pretty badly (e.g. elapsed time 30% ... I think my original SLUB versus SLAB comparisons were done on ... FWIW - swapping loads are not what anybody should tune for. ... your load eats memory quickly and kernel/swap is started to keep a low free ...
    (Linux-Kernel)
  • [GIT PULL] SLAB updates for 2.6.30-rc1
    ... Please pull the latest SLAB three which contains the following changes: ... Assorted cleanups to SLUB and SLOB ... move min_partial to struct kmem_cache ...
    (Linux-Kernel)
  • Re: tipc_init(), WARNING: at arch/x86/mm/highmem_32.c:52, [2.6.24-rc4-git5: Reported regress
    ... Which SLUB has not, we are told? ... object queues in SLAB. ... tons of memory (which is why Christoph wrote SLUB in the first place, ... The alien caches feature of SLAB i see as a spread out clustered ...
    (Linux-Kernel)