• P
    mm: Remove i_mmap_lock lockbreak · 97a89413
    Peter Zijlstra 提交于
    Hugh says:
     "The only significant loser, I think, would be page reclaim (when
      concurrent with truncation): could spin for a long time waiting for
      the i_mmap_mutex it expects would soon be dropped? "
    
    Counter points:
     - cpu contention makes the spin stop (need_resched())
     - zap pages should be freeing pages at a higher rate than reclaim
       ever can
    
    I think the simplification of the truncate code is definitely worth it.
    
    Effectively reverts: 2aa15890 ("mm: prevent concurrent
    unmap_mapping_range() on the same inode") and takes out the code that
    caused its problem.
    Signed-off-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
    Reviewed-by: NKAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
    Cc: Hugh Dickins <hughd@google.com>
    Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
    Cc: David Miller <davem@davemloft.net>
    Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
    Cc: Russell King <rmk@arm.linux.org.uk>
    Cc: Paul Mundt <lethal@linux-sh.org>
    Cc: Jeff Dike <jdike@addtoit.com>
    Cc: Richard Weinberger <richard@nod.at>
    Cc: Tony Luck <tony.luck@intel.com>
    Cc: Mel Gorman <mel@csn.ul.ie>
    Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
    Cc: Nick Piggin <npiggin@kernel.dk>
    Cc: Namhyung Kim <namhyung@gmail.com>
    Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
    Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
    97a89413
fs.h 86.4 KB