From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754750AbcE3LQd (ORCPT ); Mon, 30 May 2016 07:16:33 -0400 Received: from mga03.intel.com ([134.134.136.65]:64703 "EHLO mga03.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754542AbcE3LQc (ORCPT ); Mon, 30 May 2016 07:16:32 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.26,389,1459839600"; d="scan'208";a="987383446" Subject: Re: [PATCH] mutex: Report recursive ww_mutex locking early To: Chris Wilson , Peter Zijlstra , Ingo Molnar , intel-gfx@lists.freedesktop.org, =?UTF-8?Q?Christian_K=c3=b6nig?= , linux-kernel@vger.kernel.org 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> <322ba7ac-909d-bda5-4b1f-73e22cf10c97@linux.intel.com> <20160530102746.GA3193@twins.programming.kicks-ass.net> <20160530104547.GG30389@nuc-i3427.alporthouse.com> From: Maarten Lankhorst Message-ID: <1f1bcf7a-e1bc-e105-bcc6-8ca697fa9c4e@linux.intel.com> Date: Mon, 30 May 2016 13:16:28 +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: <20160530104547.GG30389@nuc-i3427.alporthouse.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Op 30-05-16 om 12:45 schreef Chris Wilson: > On Mon, May 30, 2016 at 12:27:46PM +0200, Peter Zijlstra wrote: >> On Mon, May 30, 2016 at 11:43:31AM +0200, Maarten Lankhorst wrote: >>> Patch not applied, SCHED_RR: >> ww_mutex isn't RT aware at all; its one of the things I still have on a >> todo list. Should I look harder at finding time for this? > The RT usage in the test is to just try and starve the kernel threads > that may be used behind the atomic modeset - a problem we have > encountered in the past. Afaik, no one is using ww_mutex from RT in the > wild, calling the atomic modeset from the RT was just a shortcut to > having the system fully populated with RT threads. To be more realistic > we should be using a couple of normal modesetting threads vs a set of RT > cpu hogs. Yeah, unfortunately this doesn't work as you intend it to. You'd need to spawn a few more threads at slightly lower priority so when a thread is blocked waiting for acquisition of the mutexes the workqueues still can't run. ssh is still responsive with the rest running. > Otoh, i915.ko always draws the ire of rt-linux so ww_mutex is likely to > be in their sights in the near future (when i915.ko completes its > transition to full atomic modesetting).