mm: avoid repeated anon_vma lock/unlock sequences in anon_vma_clone()
authorLinus Torvalds <torvalds@linux-foundation.org>
Fri, 17 Jun 2011 03:44:51 +0000 (20:44 -0700)
committerLinus Torvalds <torvalds@linux-foundation.org>
Sat, 18 Jun 2011 02:20:49 +0000 (19:20 -0700)
commitbb4aa39676f73b4657b3edd893ae83881c430c0c
tree6b8db9ed4a9e3fb6c232dd8447b0d24e76f5885a
parenteb96c925152fc289311e5d7e956b919e9b60ab53
mm: avoid repeated anon_vma lock/unlock sequences in anon_vma_clone()

In anon_vma_clone() we traverse the vma->anon_vma_chain of the source
vma, locking the anon_vma for each entry.

But they are all going to have the same root entry, which means that
we're locking and unlocking the same lock over and over again.  Which is
expensive in locked operations, but can get _really_ expensive when that
root entry sees any kind of lock contention.

In fact, Tim Chen reports a big performance regression due to this: when
we switched to use a mutex instead of a spinlock, the contention case
gets much worse.

So to alleviate this all, this commit creates a small helper function
(lock_anon_vma_root()) that can be used to take the lock just once
rather than taking and releasing it over and over again.

We still have the same "take the lock and release" it behavior in the
exit path (in unlink_anon_vmas()), but that one is a bit harder to fix
since we're actually freeing the anon_vma entries as we go, and that
will touch the lock too.

Reported-and-tested-by: Tim Chen <tim.c.chen@linux.intel.com>
Tested-by: Hugh Dickins <hughd@google.com>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Andi Kleen <ak@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
mm/rmap.c