Re: SLUB tbench regression due to page allocator deficiency

[Nick Piggin <npiggin@suse.de>]

On Mon, Feb 11, 2008 at 03:42:34PM -0800, Christoph Lameter wrote:
> On Tue, 12 Feb 2008, Nick Piggin wrote:
> 
> > It might be possible but would take quite a bit of rework (eg. have a
> > look at pcp->count and the horrible anti fragmentation loops).
> 
> Yeah. May influece the way we have to handle freelists. Sigh.
> 
> > > The fastpath use will be reduced to 50% since every other 
> > > allocation will have to go to the page allocator. Maybe we can do that 
> > > if the page allocator performance is up to snuff.
> > 
> > The page allocator has to do quite a lot more than the slab allocator
> > does. It has to check watermarks and all the NUMA and zone and anti
> > fragmentation stuff, and does quite a lot of branches and stores to
> > tes tand set up the struct page.
> > 
> > So it's never going to be as fast as a simple slab allocation.
> 
> Well but does it have to do all of that on *each* allocation?

NUMA -- because of policies and zlc
cpuset -- zone softwall stuff
Anti fragmentation -- we can't allocate pages of a different migration type
watermarks -- because of watermarks

Actually eg. my patch to avoid watermark checking for fastpath allocations
is not even very nice itself, because it can result in problems like Peter
wsa running into with slab because one PF_MEMALLOC task can refill a batch
and others can use up the rest of the memory even if they aren't allowed
to.

struct page initialization and checking -- yeah we could skip most of
this in the allocation fastpath. I don't think such a patch would be too
popular though. 

So yeah there are non-trivial issues.


> The slab 
> allocators also do quite a number of things including NUMA handling but 
> all of that is in the slow path and its not done for every single 
> allocation.

Yeah but a lot of things it either doesn't have to worry about (eg. zones,
anti fragmentation), or it sweeps under the carpet (policies, watermarks).

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