Re: SLUB tbench regression due to page allocator deficiency

[Christoph Lameter <clameter@sgi.com>]

On Sun, 10 Feb 2008, Nick Piggin wrote:

> What kind of allocating and freeing of pages are you talking about? Are
> you just measuring single threaded performance?

The tests that I did do measure a couple of scenarios. tbench seems to 
free/release page size chunks quite a bit and benefits from SLAB queueing
up the pages. tbench stays on each processor it seems, so very limited 
contention effects. The page allocator problem is simply caused by too
many instructions that need to run in order to get a page.

> Other things you can do like not looking at the watermarks if the zone
> has pcp pages avoids cacheline bouncing on SMP. 
> 
> I had a set of patches do to various little optimisations like that, but
> I don't actually know if they would help you significantly or not.
> 
> I could try a bit of profiling if you tell me what specific test you
> are interested in?

Run tbench with SLUB and tbench will hit the page allocator hard with 
page sized allocations. If you apply the patch that I provided in this 
thread then these will go away. SLUB will reduce the load on the page 
allocator like SLAB. The SLUB fastpath will stand in for the page 
allocator fastpath.




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