(added Matt to the Cc: list)
* Christoph Lameter <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
