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: <20070709230918.GX11115@waste.org>
Date:	Mon, 9 Jul 2007 18:09:19 -0500
From:	Matt Mackall <mpm@...enic.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Christoph Lameter <clameter@....com>,
	Nick Piggin <nickpiggin@...oo.com.au>,
	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>,
	Denis Vlasenko <vda.linux@...glemail.com>,
	Erik Andersen <andersen@...epoet.org>
Subject: Re: [patch 09/10] Remove the SLOB allocator for 2.6.23

On Mon, Jul 09, 2007 at 09:51:16AM -0700, Andrew Morton wrote:
> On Mon, 9 Jul 2007 09:06:46 -0700 (PDT) Christoph Lameter <clameter@....com> wrote:
> 
> > 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.
> 
> I've frequently wondered why we don't just create more caches for kmalloc:
> make it denser than each-power-of-2-plus-a-few-others-in-between.
> 
> I assume the tradeoff here is better packing versus having a ridiculous
> number of caches.  Is there any other cost?

It magnifies the fragmentation problem.

SLAB (and SLUB) makes the optimistic assumption that objects of the
same type/size have similar lifetimes. But for some objects, it's not
uncommon to do many temporary allocations but have some objects with
indefinite lifespans. dcache is a very frequently encountered example,
but there's no reason we couldn't see it with sockets and many other
object types. 

Every new arena introduces further opportunity for this sort of
fragmentation. If we had, say, separate pools for 48 byte and 64 byte
objects, an unfortunate usage pattern for 48-byte kmallocs could DoS
requests for 64 byte objects that would work just fine if they both
came out of the same pool. If we have 10 pools with long-lived
objects, we're much worse off than if we had 1 or 2.

-- 
Mathematics is the supreme nostalgia of our time.
-
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/