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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 12 Jul 2007 10:33:28 +1000
From:	Nick Piggin <nickpiggin@...oo.com.au>
To:	Pekka J Enberg <penberg@...helsinki.fi>
CC:	Christoph Lameter <clameter@....com>,
	Matt Mackall <mpm@...enic.com>,
	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, 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 J Enberg wrote:
> Hi Christoph,
> 
> On Wed, 11 Jul 2007, Christoph Lameter wrote:
> 
>>Of course you are the maintainer but you only authored a single patch 
>>which was the original submission in all the time that SLOB was in the 
>>tree. I keep having to clean up the allocator that has--according to 
>>Pekka--more memory requirements than SLUB. There is no point in keeping it 
>>around anymore it seems.
> 
> 
> Well, it was a test setup with UML and busybox and didn't have all the 
> SLOB optimizations Nick mentioned, so we shouldn't draw any definite 
> conclusions from it. I couldn't get 2.6.22-rc6-mm1 to compile so I'll try 
> again after Andrew pushes a new release out.
> 
> Furthermore, as much as I would like to see SLOB nuked too, we can't do 
> that until Matt and Nick are satisfied with SLUB for small devices and 
> what I can gather, they aren't.

Just to be clear: I do really like SLUB of course. And if that was able
to get as good or nearly as good (for appropriate values of nearly) memory
efficiency as SLOB in relevant situations, that would be fantastic and
SLOB could go away.

I don't really have a good knowledge of small memory devices being used,
other than apparently they can boot with 2MB (maybe less with nommu?). So
even a few K could be very significant for these.

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