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]

Date:	Mon, 09 Jul 2007 21:16:56 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Pekka Enberg <penberg@...helsinki.fi>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>,
	Christoph Lameter <clameter@....com>,
	linux-kernel@...r.kernel.org, linux-mm@...r.kernel.org,
	suresh.b.siddha@...el.com, corey.d.gough@...el.com,
	Matt Mackall <mpm@...enic.com>,
	Denis Vlasenko <vda.linux@...glemail.com>,
	Erik Andersen <andersen@...epoet.org>
Subject: Re: [patch 09/10] Remove the SLOB allocator for 2.6.23

Pekka Enberg wrote:
> Hi Nick,
> 
> On 7/9/07, Nick Piggin <nickpiggin@...oo.com.au> wrote:
> 
>> SLOB contains several significant O(1) and also O(n) memory savings that
>> are so far impossible-by-design for SLUB. They are: slab external
>> fragmentation is significantly reduced; kmalloc internal fragmentation is
>> significantly reduced; order of magnitude smaller kmem_cache data type;
>> order of magnitude less code...
> 
> 
> I assume with "slab external fragmentation" you mean allocating a
> whole page for a slab when there are not enough objects to fill the
> whole thing thus wasting memory?

Yep. Without really analysing it, I guess SLOB's savings here are
O(1) over SLUB and will relatively diminish as the machine size gets
larger, however with the number of slabs even a small kernel creates,
this is likely to be significant on small memory systems.

> We could try to combat that by
> packing multiple variable-sized slabs within a single page. Also,

Yeah, that could help.

> adding some non-power-of-two kmalloc caches might help with internal
> fragmentation.

That too, although of course it will work against the external
fragmentation problem. This is more of an O(n) problem and may not
be responsible for as much waste as the first issue on small memory
machines (I haven't done detailed profiling so I don't know).

> In any case, SLUB needs some serious tuning for smaller machines
> before we can get rid of SLOB.

I would always be happy to see the default allocator become more
space efficient... I think it would be most productive to get
detailed profiles of exactly where the memory is being wasted on
small mem= boots. Although I don't think matching SLOB would be
an easy task at all.

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