On Fri, Nov 01, 2013 at 07:44:29PM +0800, Yuanhan Liu wrote: > commit 012f18004da33ba672e3c60838cc4898126174d3 > Author: Rik van Riel <r...@redhat.com> > Date: Mon Aug 9 17:18:40 2010 -0700 > > mm: always lock the root (oldest) anon_vma > > Always (and only) lock the root (oldest) anon_vma whenever we do something > in an anon_vma. The recently introduced anon_vma scalability is due to > the rmap code scanning only the VMAs that need to be scanned. Many common > operations still took the anon_vma lock on the root anon_vma, so always > taking that lock is not expected to introduce any scalability issues. > > However, always taking the same lock does mean we only need to take one > lock, which means rmap_walk on pages from any anon_vma in the vma is > excluded from occurring during an munmap, expand_stack or other operation > that needs to exclude rmap_walk and similar functions. > > Also add the proper locking to vma_adjust. > > Signed-off-by: Rik van Riel <r...@redhat.com> > Tested-by: Larry Woodman <lwood...@redhat.com> > Acked-by: Larry Woodman <lwood...@redhat.com> > Reviewed-by: Minchan Kim <minchan....@gmail.com> > Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hir...@jp.fujitsu.com> > Acked-by: Mel Gorman <m...@csn.ul.ie> > Acked-by: Linus Torvalds <torva...@linux-foundation.org> > Signed-off-by: Andrew Morton <a...@linux-foundation.org> > Signed-off-by: Linus Torvalds <torva...@linux-foundation.org>
Right that commit did. I'm still not sure why you change both the locking proper and the locking primitive used in one patch set. Also, changing the locking proper requires a very detailed explanation on why it is correct; we've had far too many 'fun' issues with the anon_vma locking in the past. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
