From: Shaohua Li Date: Wed, 25 May 2011 00:11:19 +0000 (-0700) Subject: mmap: avoid unnecessary anon_vma lock X-Git-Tag: upstream/snapshot3+hdmi~10305 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=5f70b962ccc2f2e6259417cf3d1233dc9e16cf5e;hp=34679d7eac9ecc20face093db9aa610f1e9c893a;p=platform%2Fadaptation%2Frenesas_rcar%2Frenesas_kernel.git 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 Cc: Rik van Riel Acked-by: Hugh Dickins Cc: Andi Kleen Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds --- diff --git a/mm/mmap.c b/mm/mmap.c index eaec3df..15b1fae 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -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); }