linux-kernel - Re: [PATCH] SLUB: revert direct page allocator pass through

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: <1232726609.6094.106.camel@penberg-laptop>
Date:	Fri, 23 Jan 2009 18:03:29 +0200
From:	Pekka Enberg <penberg@...helsinki.fi>
To:	Christoph Lameter <cl@...ux-foundation.org>
Cc:	Nick Piggin <nickpiggin@...oo.com.au>,
	yanmin_zhang@...ux.intel.com, Andi Kleen <andi@...stfloor.org>,
	Matthew Wilcox <matthew@....cx>, linux-kernel@...r.kernel.org,
	akpm@...ux-foundation.org
Subject: Re: [PATCH] SLUB: revert direct page allocator pass through

On Sat, 24 Jan 2009, Nick Piggin wrote:
> > However, I don't know if netperf udp 4K over loopback is totally
> > realistic. Maybe real network drivers have different allocation patterns.
> > If I were you I wouldn't be too hasty to make big changes based on that
> > alone, if it could introduce regression in somewhere more important.

On Fri, 2009-01-23 at 10:57 -0500, Christoph Lameter wrote:
> AFAICT it just wastes memory. My idea of a slab allocator is that it is
> used for small (less than page sized) allocations. The page allocator
> should be able to handle page sized allocations in an effective manner.

FWIW, based on my results, it's actually the big objects that are so
badly fitting which causes much of the wasted memory. So I'd prefer to
get rid of the page allocator completely for kmalloc() and just use a
best fit allocator for everything. Something like my binalloc. ;-)

			Pekka

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