mm: mremap: downgrade mmap_sem to read when shrinking
authorYang Shi <[email protected]>
Fri, 26 Oct 2018 22:08:50 +0000 (15:08 -0700)
committerLinus Torvalds <[email protected]>
Fri, 26 Oct 2018 23:26:35 +0000 (16:26 -0700)
commit85a06835f6f1ba79f0f00838ccd5ad840dd1eafb
tree91ec31587d1e465de5d5940a11f469695c7320a3
parent3c0513243a4a07ebad2d59f3d972bef483818ec6
mm: mremap: downgrade mmap_sem to read when shrinking

Other than munmap, mremap might be used to shrink memory mapping too.
So, it may hold write mmap_sem for long time when shrinking large
mapping, as what commit ("mm: mmap: zap pages with read mmap_sem in
munmap") described.

The mremap() will not manipulate vmas anymore after __do_munmap() call for
the mapping shrink use case, so it is safe to downgrade to read mmap_sem.

So, the same optimization, which downgrades mmap_sem to read for zapping
pages, is also feasible and reasonable to this case.

The period of holding exclusive mmap_sem for shrinking large mapping
would be reduced significantly with this optimization.

MREMAP_FIXED and MREMAP_MAYMOVE are more complicated to adopt this
optimization since they need manipulate vmas after do_munmap(),
downgrading mmap_sem may create race window.

Simple mapping shrink is the low hanging fruit, and it may cover the
most cases of unmap with munmap together.

[[email protected]: tweak comment]
[[email protected]: fix unsigned compare against 0 issue]
Link: http://lkml.kernel.org/r/[email protected]
Link: http://lkml.kernel.org/r/[email protected]
Signed-off-by: Yang Shi <[email protected]>
Acked-by: Vlastimil Babka <[email protected]>
Acked-by: Kirill A. Shutemov <[email protected]>
Cc: Michal Hocko <[email protected]>
Cc: Matthew Wilcox <[email protected]>
Cc: Laurent Dufour <[email protected]>
Cc: Colin Ian King <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
include/linux/mm.h
mm/mmap.c
mm/mremap.c