• V
    sched/numa: Use down_read_trylock() for the mmap_sem · 8655d549
    Vlastimil Babka 提交于
    A customer has reported a soft-lockup when running an intensive
    memory stress test, where the trace on multiple CPU's looks like this:
    
     RIP: 0010:[<ffffffff810c53fe>]
      [<ffffffff810c53fe>] native_queued_spin_lock_slowpath+0x10e/0x190
    ...
     Call Trace:
      [<ffffffff81182d07>] queued_spin_lock_slowpath+0x7/0xa
      [<ffffffff811bc331>] change_protection_range+0x3b1/0x930
      [<ffffffff811d4be8>] change_prot_numa+0x18/0x30
      [<ffffffff810adefe>] task_numa_work+0x1fe/0x310
      [<ffffffff81098322>] task_work_run+0x72/0x90
    
    Further investigation showed that the lock contention here is pmd_lock().
    
    The task_numa_work() function makes sure that only one thread is let to perform
    the work in a single scan period (via cmpxchg), but if there's a thread with
    mmap_sem locked for writing for several periods, multiple threads in
    task_numa_work() can build up a convoy waiting for mmap_sem for read and then
    all get unblocked at once.
    
    This patch changes the down_read() to the trylock version, which prevents the
    build up. For a workload experiencing mmap_sem contention, it's probably better
    to postpone the NUMA balancing work anyway. This seems to have fixed the soft
    lockups involving pmd_lock(), which is in line with the convoy theory.
    Signed-off-by: NVlastimil Babka <vbabka@suse.cz>
    Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
    Acked-by: NRik van Riel <riel@redhat.com>
    Acked-by: NMel Gorman <mgorman@techsingularity.net>
    Cc: Linus Torvalds <torvalds@linux-foundation.org>
    Cc: Peter Zijlstra <peterz@infradead.org>
    Cc: Thomas Gleixner <tglx@linutronix.de>
    Link: http://lkml.kernel.org/r/20170515131316.21909-1-vbabka@suse.czSigned-off-by: NIngo Molnar <mingo@kernel.org>
    8655d549
fair.c 248.3 KB