lkml.org 
[lkml]   [2009]   [Sep]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: aim7 scalability issue on 4 socket machine

* Zhang, Yanmin <yanmin_zhang@linux.intel.com> 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%.

Impressive speedup!

[ Also, the array of tools you used to debug this is impressive as well
;-) ]

Ingo


\
 
 \ /
  Last update: 2009-09-17 12:37    [from the cache]
©2003-2011 Jasper Spaans