[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161108132448.GG3117@twins.programming.kicks-ass.net>
Date: Tue, 8 Nov 2016 14:24:48 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: Stephen Rothwell <sfr@...b.auug.org.au>,
Thomas Gleixner <tglx@...utronix.de>,
Ingo Molnar <mingo@...e.hu>, "H. Peter Anvin" <hpa@...or.com>,
Intel Graphics <intel-gfx@...ts.freedesktop.org>,
DRI <dri-devel@...ts.freedesktop.org>,
linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
Chris Wilson <chris@...is-wilson.co.uk>
Subject: Re: linux-next: manual merge of the tip tree with the drm-intel tree
On Tue, Nov 08, 2016 at 11:44:03AM +0100, Daniel Vetter wrote:
> On Tue, Nov 08, 2016 at 03:25:41PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > FIXME: Add owner of second tree to To:
> > Add author(s)/SOB of conflicting commits.
> >
> > Today's linux-next merge of the tip tree got a conflict in:
> >
> > drivers/gpu/drm/i915/i915_gem_shrinker.c
> >
> > between commits:
> >
> > 1233e2db199d ("drm/i915: Move object backing storage manipulation to its own locking")
> >
> > from the drm-intel tree and commit:
> >
> > 3ab7c086d5ec ("locking/drm: Kill mutex trickery")
> > c7faee2109f9 ("locking/drm: Fix i915_gem_shrinker_lock() locking")
>
> Hm, this seems to be the older versions that nuke the recursive locking
> trickery entirely, I thought we had version in-flight that kept that? I
> know that the i915 (and msm locking fwiw) is horrible since essentially
> it's a recursive BKL, and we're working (slowly, after all getting rid of
> the BKL wasn't simple either) to fix this. But meanwhile I'm assuming that
> we'll still need this to be able to get out of low memory situations in
> i915. Has that part simply not yet landed?
You're talking about:
lkml.kernel.org/r/20161007154351.GL3117@...ns.programming.kicks-ass.net
? I got no feedback from you DRM guys on that so I kinda forgot about
that in the hope we'd not have to do this at all.
I can try and resurrect, that I suppose.
Now, I know you're working on getting rid of this entirely for i915, but
what about that MSM driver? Will we continue to need it there, is
anybody actually maintaining that thing?
Powered by blists - more mailing lists