mm: avoid taking rmap locks in move_ptes()
authorMichel Lespinasse <[email protected]>
Mon, 8 Oct 2012 23:31:50 +0000 (16:31 -0700)
committerLinus Torvalds <[email protected]>
Tue, 9 Oct 2012 07:22:42 +0000 (16:22 +0900)
commit38a76013ad809beb0b52f60d365c960d035bd83c
treec63ba707ab17dd1ff1e90650faf74570daa3cf9f
parent523d4e2008fd4a68b1a164e63e8c75b7b20f07e0
mm: avoid taking rmap locks in move_ptes()

During mremap(), the destination VMA is generally placed after the
original vma in rmap traversal order: in move_vma(), we always have
new_pgoff >= vma->vm_pgoff, and as a result new_vma->vm_pgoff >=
vma->vm_pgoff unless vma_merge() merged the new vma with an adjacent one.

When the destination VMA is placed after the original in rmap traversal
order, we can avoid taking the rmap locks in move_ptes().

Essentially, this reintroduces the optimization that had been disabled in
"mm anon rmap: remove anon_vma_moveto_tail".  The difference is that we
don't try to impose the rmap traversal order; instead we just rely on
things being in the desired order in the common case and fall back to
taking locks in the uncommon case.  Also we skip the i_mmap_mutex in
addition to the anon_vma lock: in both cases, the vmas are traversed in
increasing vm_pgoff order with ties resolved in tree insertion order.

Signed-off-by: Michel Lespinasse <[email protected]>
Cc: Andrea Arcangeli <[email protected]>
Cc: Rik van Riel <[email protected]>
Cc: Peter Zijlstra <[email protected]>
Cc: Daniel Santos <[email protected]>
Cc: Hugh Dickins <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
fs/exec.c
include/linux/mm.h
mm/mmap.c
mm/mremap.c