Re: 2.6.24-rc2: Network commit causes SLUB performance regression with tbench

[Nick Piggin <nickpiggin@yahoo.com.au>]

On Thursday 15 November 2007 12:11, Herbert Xu wrote:
> On Wed, Nov 14, 2007 at 05:03:25PM -0800, Christoph Lameter wrote:
> > Well this is likely the result of the SLUB regression. If you allocate an
> > order 1 page then the zone locks need to be taken. SLAB queues the a

Yeah, it appears this is what happened. The lockless page allocator
fastpath appears on the list and the slowpaths disappear after
Herbert's patches. SLAB is doing its own thing, so it avoids that
pitfall.


> > couple of higher order pages and can so serve a couple of requests
> > without going into the page allocator whereas SLUB has to go directly to
> > the page allocator for allocate and free. I guess that needs fixing in
> > the page allocator. Or do I need to add a mechanism to buffer higher
> > order page allcoations to SLUB?
>
> Actually this serves to discourage people from using high-order
> allocations which IMHO is a good thing :)

Yeah I completely agree. The right fix is in the caller...
The bug / suboptimal allocation would not have been found in tcp
if not for this ;)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/