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


(added Matt to the Cc: list)

* Christoph Lameter <clameter@xxxxxxx> wrote:

Maintenance of slab allocators becomes a problem as new features for
allocators are developed. The SLOB allocator in particular has been
lagging behind in many ways in the past:

- Had no support for SLAB_DESTROY_BY_RCU for years (but no one
noticed)

- Still has no support for slab reclaim counters. This may currently
not be necessary if one would restrict the supported configurations
for functionality relying on these. But even that has not been done.

The only current advantage over SLUB in terms of memory savings is
through SLOBs kmalloc layout that is not power of two based like SLAB
and SLUB which allows to eliminate some memory waste.

Through that SLOB has still a slight memory advantage over SLUB of
~350k in for a standard server configuration. It is likely that the
savings are is smaller for real embedded configurations that have less
functionality.

actually, one real advantage of the SLOB is that it is a minimal, really
simple allocator. Its text and data size is so small as well.

here's the size comparison:

text data bss dec hex filename
10788 837 16 11641 2d79 mm/slab.o
6205 4207 124 10536 2928 mm/slub.o
1640 44 4 1688 698 mm/slob.o

slab/slub have roughly the same footprint, but slob is 10% of that size.
Would be a waste to throw this away.

A year ago the -rt kernel defaulted to the SLOB for a few releases, and
barring some initial scalability issues (which were solved in -rt) it
worked pretty well on generic PCs, so i dont buy the 'it doesnt work'
argument either.

Ingo
-
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: 2.6.22 -mm merge plans: slub
    ... running of two allocator for some time to make sure that it behaves in all ... load situations. ... I am pretty sure that SLUB can replace SLOB completely ...
    (Linux-Kernel)
  • [RFC2] non-power of 2 allocator for noMMU Linux
    ... > So you get a po2 block of memory and return the excess to the single ... All available memory is turned into a super slob and, if you ask for an allocation of order size 4 or more then you will get the exact number of pages you need to satisfy your memory size request. ... AS you free memory the block of pages is added back into the pool and also added to a "free memory" list. ... The difference between this and the older 2.4 NP2 allocator is the fact that the free page bit map is no longer needed. ...
    (Linux-Kernel)
  • [patch 09/10] Remove the SLOB allocator for 2.6.23
    ... The SLOB allocator in particular has been lagging ... Still has no support for slab reclaim counters. ... The density of non kmalloc slabs is superior in SLUB since SLOB has the need ...
    (Linux-Kernel)
  • Re: [PATCH] procfs: provide slubs /proc/slabinfo
    ... Mismatching allocator and deallocator is bug, ... So SLOB is then not able to compact memory after an updatedb run? ... memory must stay dedicated to slab uses. ...
    (Linux-Kernel)
  • [PATCH 2/2] slob: introduce the SLOB allocator
    ... the kernel falls back to using the 'SLOB' allocator. ... SLOB is a traditional K&R/UNIX allocator with a SLAB emulation layer, ... +static void *slob_alloc ...
    (Linux-Kernel)
Loading