Re: SLUB tbench regression due to page allocator deficiency

[Christoph Lameter <clameter@sgi.com>]

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

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