lkml.org 
[lkml]   [2008]   [Mar]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: hackbench regression since 2.6.25-rc
From
Date
On Fri, 2008-03-14 at 14:08 -0700, Christoph Lameter wrote:
> 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.

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



\
 
 \ /
  Last update: 2008-03-17 04:11    [W:0.143 / U:0.748 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site