linux-kernel - Re: aim7 scalability issue on 4 socket machine

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.64.0909171122180.25864@sister.anvils>
Date:	Thu, 17 Sep 2009 11:35:54 +0100 (BST)
From:	Hugh Dickins <hugh.dickins@...cali.co.uk>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
cc:	"Zhang, Yanmin" <yanmin_zhang@...ux.intel.com>,
	LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Arjan van de Ven <arjan@...ux.intel.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andi Kleen <andi@...stfloor.org>,
	"lee.schermerhorn@...com" <lee.schermerhorn@...com>
Subject: Re: aim7 scalability issue on 4 socket machine

On Thu, 17 Sep 2009, Peter Zijlstra wrote:
> On Thu, 2009-09-17 at 17:31 +0800, Zhang, Yanmin wrote:
> > Aim7 result is bad on my new Nehalem machines (4*8*2 logical cpu). Perf counter
> > shows spinlock consumes 70% cpu time on the machine. Lock_stat shows
> > anon_vma->lock causes most of the spinlock contention. Function tracer shows
> > below call chain creates the spinlock.
> > 
> > do_brk => vma_merge =>vma_adjust
> > 
> > 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.
> > 
> > There is a comment section in front of spin_lock(&anon_vma->lock. It says
> > anon_vma lock can be optimized when just changing vma->vm_end. As a matter
> > of fact, anon_vma->lock is used to protect anon_vma->list when an entry is
> > deleted/inserted or the list is accessed. There is no such deletion/insertion
> > if only vma->end is changed in function vma_adjust.
> > 
> > Below patch fixes it.
> > 
> > Test results with kernel 2.6.31-rc8. The improvement on the machine is about 150%.
> 
> 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.

Hugh
--
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/