[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160530104547.GG30389@nuc-i3427.alporthouse.com>
Date: Mon, 30 May 2016 11:45:47 +0100
From: Chris Wilson <chris@...is-wilson.co.uk>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>,
Ingo Molnar <mingo@...hat.com>,
intel-gfx@...ts.freedesktop.org,
Christian König <christian.koenig@....com>,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mutex: Report recursive ww_mutex locking early
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.
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).
-Chris
--
Chris Wilson, Intel Open Source Technology Centre
Powered by blists - more mailing lists