• L
    mm: avoid anon_vma_chain allocation under anon_vma lock · dd34739c
    Linus Torvalds 提交于
    Hugh Dickins points out that lockdep (correctly) spots a potential
    deadlock on the anon_vma lock, because we now do a GFP_KERNEL allocation
    of anon_vma_chain while doing anon_vma_clone().  The problem is that
    page reclaim will want to take the anon_vma lock of any anonymous pages
    that it will try to reclaim.
    
    So re-organize the code in anon_vma_clone() slightly: first do just a
    GFP_NOWAIT allocation, which will usually work fine.  But if that fails,
    let's just drop the lock and re-do the allocation, now with GFP_KERNEL.
    
    End result: not only do we avoid the locking problem, this also ends up
    getting better concurrency in case the allocation does need to block.
    Tim Chen reports that with all these anon_vma locking tweaks, we're now
    almost back up to the spinlock performance.
    Reported-and-tested-by: NHugh Dickins <hughd@google.com>
    Tested-by: NTim Chen <tim.c.chen@linux.intel.com>
    Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
    Cc: Andi Kleen <ak@linux.intel.com>
    Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
    dd34739c
rmap.c 50.2 KB