Messages in this thread | | | Date | Fri, 1 Nov 2013 13:07:45 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH 1/4] mm/rmap: per anon_vma lock |
| |
On Fri, Nov 01, 2013 at 07:44:29PM +0800, Yuanhan Liu wrote: > commit 012f18004da33ba672e3c60838cc4898126174d3 > Author: Rik van Riel <riel@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 <riel@redhat.com> > Tested-by: Larry Woodman <lwoodman@redhat.com> > Acked-by: Larry Woodman <lwoodman@redhat.com> > Reviewed-by: Minchan Kim <minchan.kim@gmail.com> > Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> > Acked-by: Mel Gorman <mel@csn.ul.ie> > Acked-by: Linus Torvalds <torvalds@linux-foundation.org> > Signed-off-by: Andrew Morton <akpm@linux-foundation.org> > Signed-off-by: Linus Torvalds <torvalds@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.
| |