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: <4692E3BF.9010305@yahoo.com.au>
Date:	Tue, 10 Jul 2007 11:41:19 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Christoph Lameter <clameter@....com>
CC:	Andrew Morton <akpm@...ux-foundation.org>,
	Ingo Molnar <mingo@...e.hu>, 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>,
	Denis Vlasenko <vda.linux@...glemail.com>,
	Erik Andersen <andersen@...epoet.org>
Subject: Re: [patch 09/10] Remove the SLOB allocator for 2.6.23

Christoph Lameter wrote:
> On Mon, 9 Jul 2007, Nick Piggin wrote:
> 
> 
>>>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.
>>
>>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...
> 
> 
> Well that is only true for kmalloc objects < PAGE_SIZE and to some extend 
> offset by the need to keep per object data in SLUB. But yes the power of 
> two caches are a necessary design feature of SLAB/SLUB that allows O(1) 
> operations of kmalloc slabs which in turns causes memory wastage because 
> of rounding of the alloc to the next power of two. SLUB has less wastage
> there than SLAB since it can fit power of two object tightly into a slab 
> instead of having to place additional control information there like SLAB.

OK but we're talking about SLOB. And the number that matters is the amount
of memory used, which is higher with SLUB than with SLOB in our tests.


> O(n) memory savings? What is that?

Allocate n things and your memory waste is proportional to n (well that's
O(n) waste, so I guess by savings I mean that SLOB's memory saving compared
to SLUB are proportional to n).

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