Messages in this thread | | | Subject | Re: hackbench regression since 2.6.25-rc | From | "Zhang, Yanmin" <> | Date | Mon, 17 Mar 2008 11:05:36 +0800 |
| |
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. > > >
| |