mmap: avoid unnecessary anon_vma lock
If we only change vma->vm_end, we can avoid taking anon_vma lock even if 'insert' isn't NULL, which is the case of split_vma. As I understand it, we need the lock before because rmap must get the 'insert' VMA when we adjust old VMA's vm_end (the 'insert' VMA is linked to anon_vma list in __insert_vm_struct before). But now this isn't true any more. The 'insert' VMA is already linked to anon_vma list in __split_vma(with anon_vma_clone()) instead of __insert_vm_struct. There is no race rmap can't get required VMAs. So the anon_vma lock is unnecessary, and this can reduce one locking in brk case and improve scalability. Signed-off-by: Shaohua Li<shaohua.li@intel.com> Cc: Rik van Riel <riel@redhat.com> Acked-by: Hugh Dickins <hughd@google.com> Cc: Andi Kleen <andi@firstfloor.org> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This commit is contained in:
parent
34679d7eac
commit
5f70b962cc
|
@ -609,7 +609,7 @@ again: remove_next = 1 + (end > next->vm_end);
|
|||
* lock may be shared between many sibling processes. Skipping
|
||||
* the lock for brk adjustments makes a difference sometimes.
|
||||
*/
|
||||
if (vma->anon_vma && (insert || importer || start != vma->vm_start)) {
|
||||
if (vma->anon_vma && (importer || start != vma->vm_start)) {
|
||||
anon_vma = vma->anon_vma;
|
||||
anon_vma_lock(anon_vma);
|
||||
}
|
||||
|
|
Loading…
Reference in New Issue