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

On Sun, 8 Jul 2007 09:51:19 +0200 Ingo Molnar <mingo@xxxxxxx> wrote:


(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.


I don't think a saving of a few k of text would justify slob's retention.

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.


Guys, look at this the other way. Suppose we only had slub, and someone
came along and said "here's a whole new allocator which saves 4.5k of
text", would we merge it on that basis? Hell no, it's not worth it. What
we might do is to get motivated to see if we can make slub less porky under
appropriate config settings.


Let's not get sentimental about these things: in general, if there's any
reasonable way in which we can rid ourselves of any code at all, we should
do so, no?
-
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)
  • [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)
  • [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)
  • [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)
  • Re: lockdep complaints in slab allocator
    ... to tell me they're shipping 100k units/mo to be confident that SLOB is ... but the user is still left with a decision of which slab allocator ... If slob could be merged into another allocator, ...
    (Linux-Kernel)
Loading