From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934637AbdEOOfl (ORCPT ); Mon, 15 May 2017 10:35:41 -0400 Received: from outbound-smtp06.blacknight.com ([81.17.249.39]:38293 "EHLO outbound-smtp06.blacknight.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934356AbdEOOfj (ORCPT ); Mon, 15 May 2017 10:35:39 -0400 Date: Mon, 15 May 2017 15:35:37 +0100 From: Mel Gorman To: Vlastimil Babka Cc: Ingo Molnar , Peter Zijlstra , Rik van Riel , linux-kernel@vger.kernel.org Subject: Re: [PATCH] sched/numa: use down_read_trylock for mmap_sem Message-ID: <20170515143537.bxnjgt226ncdgifh@techsingularity.net> References: <20170515131316.21909-1-vbabka@suse.cz> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <20170515131316.21909-1-vbabka@suse.cz> User-Agent: Mutt/1.6.2 (2016-07-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, May 15, 2017 at 03:13:16PM +0200, Vlastimil Babka wrote: > A customer has reported a soft-lockup when running a proprietary intensive > memory stress test, where the trace on multiple CPU's looks like this: > > RIP: 0010:[] > [] native_queued_spin_lock_slowpath+0x10e/0x190 > ... > Call Trace: > [] queued_spin_lock_slowpath+0x7/0xa > [] change_protection_range+0x3b1/0x930 > [] change_prot_numa+0x18/0x30 > [] task_numa_work+0x1fe/0x310 > [] 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: Vlastimil Babka This skips the entire scan window and defers to the next once. Potentially, with constant contention, it'll never make progress and there could be other disruption. However, I cannot see any way how that's worse than waiting on mmap_sem so Acked-by: Mel Gorman -- Mel Gorman SUSE Labs