On Fri, 2008-03-14 at 14:08 -0700, Christoph Lameter wrote:
quoted text
> On Fri, 14 Mar 2008, Zhang, Yanmin wrote:
> 
> > > Ahhh... Okay those slabs did not change for 2.6.25-rc. Is there
> > > really a difference to 2.6.24?
> > As oprofile shows slub functions spend more than 80% cpu time, I would like
> > to focus on optimizing SLUB before going back to 2.6.24.
> 
> I thought you wanted to address a regression vs 2.6.24?
Initially I wanted to do so, but oprofile data showed both 2.6.24 and 2.6.25-rc
aren't good with hachbench on tigerton.

The slub_min_objects boot parameter could boost performance largely. So I think
we need optimize it before addressing the regression.

quoted text
> 
> > kmalloc-512: No NUMA information available.
> > 
> > Slab Perf Counter       Alloc     Free %Al %Fr
> > --------------------------------------------------
> > Fastpath             55039159  5006829  68   6
> > Slowpath             24975754 75007769  31  93
> > Page Alloc              73840    73779   0   0
> > Add partial                 0 24341085   0  30
> > Remove partial       24267297    73779  30   0
> 
> ^^^ add partial/remove partial is likely the cause for 
> trouble here. 30% is unacceptably high. The larger allocs will reduce the 
> partial handling overhead. That is likely the effect that we see here.
> 
> > Refill 24975738
> 
> Duh refills at 50%? We could try to just switch to another slab instead of 
> reusing the existing one. May also affect the add/remove partial 
> situation.
> 
> 
> 

--
unsubscribe notice
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/