linux-kernel - Re: lockdep complaints in slab allocator

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: <alpine.DEB.2.00.0911241336550.12339@chino.kir.corp.google.com>
Date:	Tue, 24 Nov 2009 13:46:34 -0800 (PST)
From:	David Rientjes <rientjes@...gle.com>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	Matt Mackall <mpm@...enic.com>, paulmck@...ux.vnet.ibm.com,
	Pekka Enberg <penberg@...helsinki.fi>, linux-mm@...ck.org,
	Christoph Lameter <cl@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Nick Piggin <npiggin@...e.de>
Subject: Re: lockdep complaints in slab allocator

On Tue, 24 Nov 2009, Peter Zijlstra wrote:

> We should cull something, just merging more and more of them is useless
> and wastes everybody's time since you have to add features and
> interfaces to all of them.
> 

I agree, but it's difficult to get widespread testing or development 
interest in an allocator that is sitting outside of mainline.  I don't 
think any allocator could suddenly be merged as the kernel default, it 
seems like a prerequisite to go through the preliminary merging and 
development.  The severe netperf TCP_RR regression that slub has compared 
to slab was never found before it became the default allocator, otherwise 
there would probably have been more effort into its development as well.  
Unfortunately, slub's design is such that it will probably never be able 
to nullify the partial slab thrashing enough, even with the percpu counter 
speedup that is now available because of Christoph's work, to make TCP_RR 
perform as well as slab.

> Then maybe we should toss SLUB? But then there's people who say SLUB is
> better for them. Without forcing something to happen we'll be stuck with
> multiple allocators forever.
> 

Slub is definitely superior in diagnostics and is a much simpler design 
than slab.  I think it would be much easier to remove slub than slab, 
though, simply because there are no great slab performance degradations 
compared to slub.  I think the best candidate for removal might be slob, 
however, because it hasn't been compared to slub and usage may not be as 
widespread as expected for such a special case allocator.
--
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/