Re: [RFC V2 SLEB 00/14] The Enhanced(hopefully) Slab Allocator

[Nick Piggin <npiggin@suse.de>]

On Tue, May 25, 2010 at 10:28:11AM -0500, Christoph Lameter wrote:
> On Wed, 26 May 2010, Nick Piggin wrote:
> 
> > You do not understand. There is nothing *preventing* other designs of
> > allocators from using higher order allocations. The problem is that
> > SLUB is *forced* to use them due to it's limited queueing capabilities.
> 
> SLUBs use of higher order allocation is *optional*. The limited queuing is
> advantageous within the framework of SLUB because NUMA locality checks are
> simplified and locking is localized to a single page increasing
> concurrency.

It's not optional if performance sucks without it. People want to have
a well performing slab allocator and also not have the downsides of it
using higher order allocations.

Look at what David said about Google's kernel for a concrete example.

 
> > You keep spinning this as a good thing for SLUB design when it is not.
> 
> It is a good design decision. You have an irrational fear of higher order
> allocations.

No.

 
> > > The reason that the alien caches made it into SLAB were performance
> > > numbers that showed that the design "must" be this way. I prefer a clear
> > > maintainable design over some numbers (that invariably show the bias of
> > > the tester for certain loads).
> >
> > I don't really agree. There are a number of other possible ways to
> > improve it, including fewer remote freeing queues.
> 
> You disagree with the history of the allocator?

I don't agree with you saying that it "must" be that way. There are
other ways to improve things there.


> > How is it possibly better to instead start from the known suboptimal
> > code and make changes to it? What exactly is your concern with
> > making incremental changes to SLAB?
> 
> I am not sure why you want me to repeat what I already said. Guess we
> should stop this conversation since it is deteriorating.

You never answered these questions adequately. These are the 2 most
important things because if I can address your concerns with them,
then we can go ahead and throw out SLUB and make incremental
improvements from there instead.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>