[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1253243877.2606.46.camel@ymzhang>
Date: Fri, 18 Sep 2009 11:17:57 +0800
From: "Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Hugh Dickins <hugh.dickins@...cali.co.uk>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
Arjan van de Ven <arjan@...ux.intel.com>,
Andi Kleen <andi@...stfloor.org>,
"lee.schermerhorn@...com" <lee.schermerhorn@...com>
Subject: Re: aim7 scalability issue on 4 socket machine
On Thu, 2009-09-17 at 19:59 -0700, Andrew Morton wrote:
> On Fri, 18 Sep 2009 10:02:19 +0800 "Zhang, Yanmin" <yanmin_zhang@...ux.intel.com> wrote:
>
> > > > Did you see Lee's patch?:
> > > >
> > > > http://lkml.org/lkml/2009/9/9/290
> > > >
> > > > Added Lee and Hugh to CC, retained the below patch for them.
> > >
> > > Thanks a lot for the CC, Peter.
> > > See my reply to that mail for the slightly corrected version.
> > >
> > > Yes, Yanmin and Lee appear to be fixing exactly the same issue.
> > > I haven't thought through Yanmin's version for correctness, but
> > > it lacks the vm_start check I added to Lee's, and I do prefer
> > > Lee's style - hey, nothing personal!
> > >
> > > So, Yanmin, please retest with http://lkml.org/lkml/2009/9/13/25
> > > and let us know if that works as well for you - thanks.
> > I tested Lee's patch and it does fix the issue.
>
> Do we think we should cook up something for -stable?
It's better to have a patch for -stable.
>
> Either this is a regression or the workload is particularly obscure.
This issue is not clear on dual socket Nehalem machine (2*4*2 cpu), but
is severe on large machine (4*8*2 cpu).
>
> aim7 is sufficiently non-obscure to make me wonder what's happened here?
I copy previous content below:
Aim7 consists of lots of subtests. One test is to fork lots of processes and
every process calls sbrk for 1000 times to grow/shrink the heap. All the vma of
the heap of all sub-processes point to the same anon_vma and use the same
anon_vma->lock. When sbrk is called, kernel calls do_brk => vma_merge =>vma_adjust
and lock anon_vma->lock to create spinlock contentions.
--
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