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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20070708110224.9cd9df5b.akpm@linux-foundation.org>
Date:	Sun, 8 Jul 2007 11:02:24 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Christoph Lameter <clameter@....com>, linux-kernel@...r.kernel.org,
	linux-mm@...r.kernel.org, suresh.b.siddha@...el.com,
	corey.d.gough@...el.com, Pekka Enberg <penberg@...helsinki.fi>,
	Matt Mackall <mpm@...enic.com>
Subject: Re: [patch 09/10] Remove the SLOB allocator for 2.6.23

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

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