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: <4690B1A4.4010703@yahoo.com.au>
Date:	Sun, 08 Jul 2007 19:43:00 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
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>,
	akpm@...ux-foundation.org, Matt Mackall <mpm@...enic.com>
Subject: Re: [patch 09/10] Remove the SLOB allocator for 2.6.23

Ingo Molnar 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)

It likely was not frequently used on SMP, I guess.

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

SLOB has so far run fine without any of these, hasn't it?

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

Wrong. All "slabs" allocate out of the same pool of memory in SLOB, so
you also wind up with less waste via _external_ fragmentation, which is
espeically important on small memory machines (the kmalloc layout issue
is a problem of internal fragmentation). SLOB is also smaller and simpler
code as Ingo pointed out.

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

When I last tested, I got similar savings with a pretty stripped down
kernel and a small mem= available RAM. Ie. to the point where those 350K
saved were a very significant chunk of remaining free memory after init
comes up.

I said exactly the same thing last time this came up. I would love to
remove code if its functionality can be adequately replaced by existing
code, but I think your reasons for removing SLOB aren't that good, and
just handwaving away the significant memory savings doesn't work.

People run 2.6 kernels with several MB of RAM, don't they? So losing
several hundred K is as bad to them as a patch that causes an Altix to
waste several hundred GB is to you.

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

It's actually recently been made to work on SMP, it is much more scalable
to large memories, and some initial NUMA work is happening that some
embedded guys are interested in, all without increasing static footprint
too much, and it has actually decreased dynamic footprint too.

-- 
SUSE Labs, Novell Inc.
-
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/