From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754527AbcE3Jnf (ORCPT ); Mon, 30 May 2016 05:43:35 -0400 Received: from mga02.intel.com ([134.134.136.20]:40188 "EHLO mga02.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754412AbcE3Jne (ORCPT ); Mon, 30 May 2016 05:43:34 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,389,1459839600"; d="scan'208";a="991458108" Subject: Re: [PATCH] mutex: Report recursive ww_mutex locking early To: Peter Zijlstra References: <1464251487-23778-1-git-send-email-chris@chris-wilson.co.uk> <1464293297-19777-1-git-send-email-chris@chris-wilson.co.uk> <4271f89a-ab98-2d97-fccb-3527931597ec@linux.intel.com> <20160530091116.GP3192@twins.programming.kicks-ass.net> Cc: Chris Wilson , Ingo Molnar , intel-gfx@lists.freedesktop.org, =?UTF-8?Q?Christian_K=c3=b6nig?= , linux-kernel@vger.kernel.org From: Maarten Lankhorst Message-ID: <322ba7ac-909d-bda5-4b1f-73e22cf10c97@linux.intel.com> Date: Mon, 30 May 2016 11:43:31 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 MIME-Version: 1.0 In-Reply-To: <20160530091116.GP3192@twins.programming.kicks-ass.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Op 30-05-16 om 11:11 schreef Peter Zijlstra: > On Mon, May 30, 2016 at 09:43:53AM +0200, Maarten Lankhorst wrote: >> Op 26-05-16 om 22:08 schreef Chris Wilson: >>> Recursive locking for ww_mutexes was originally conceived as an >>> exception. However, it is heavily used by the DRM atomic modesetting >>> code. Currently, the recursive deadlock is checked after we have queued >>> up for a busy-spin and as we never release the lock, we spin until >>> kicked, whereupon the deadlock is discovered and reported. >>> >>> A simple solution for the now common problem is to move the recursive >>> deadlock discovery to the first action when taking the ww_mutex. >>> >>> Testcase: igt/kms_cursor_legacy > I've no idea what this tag is or where to find the actual testcase, so > I've killed it. https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/ tests/kms_cursor_legacy tries to do as many updates as possible with SCHED_RR.. Patch not applied, SCHED_RR: # ./kms_cursor_legacy IGT-Version: 1.14-g9579e5447aa3 (x86_64) (Linux: 4.6.0-patser+ x86_64) [3] count=86 [2] count=91 [1] count=78 [0] count=104 Subtest stress-bo: SUCCESS (22,372s) Patch not applied, SCHED_NORMAL: # ./kms_cursor_legacy IGT-Version: 1.14-g9579e5447aa3 (x86_64) (Linux: 4.6.0-patser+ x86_64) [2] count=4713 [0] count=4288 [3] count=4776 [1] count=4521 Subtest stress-bo: SUCCESS (21,492s) Patch applied, NORMAL + RR give roughly same results: # nfs/intel-gpu-tools/tests/kms_cursor_legacy IGT-Version: 1.14-g9579e5447aa3 (x86_64) (Linux: 4.6.0-patser+ x86_64) [0] count=77631 [1] count=77740 [3] count=77612 [2] count=77666 Subtest stress-bo: SUCCESS (21,487s) >>> Suggested-by: Maarten Lankhorst >>> Signed-off-by: Chris Wilson >>> Cc: Peter Zijlstra >>> Cc: Ingo Molnar >>> Cc: Christian König >>> Cc: Maarten Lankhorst >>> Cc: linux-kernel@vger.kernel.org >>> --- >>> >>> Maarten suggested this as a simpler fix to the immediate problem. Imo, >>> we still want to perform deadlock detection within the spin in order to >>> catch more complicated deadlocks without osq_lock() forcing fairness! >> Reviewed-by: Maarten Lankhorst >> >> Should this be Cc: stable@vger.kernel.org ? > Can do; how far back? >