[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0803141356540.28115@schroedinger.engr.sgi.com>
Date: Fri, 14 Mar 2008 14:08:36 -0700 (PDT)
From: Christoph Lameter <clameter@....com>
To: "Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>
cc: Andrew Morton <akpm@...ux-foundation.org>,
Kay Sievers <kay.sievers@...y.org>,
Greg Kroah-Hartman <gregkh@...e.de>,
LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>
Subject: Re: hackbench regression since 2.6.25-rc
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?
> 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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists