[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 11 Nov 2016 12:22:02 +0100
From: Daniel Vetter <daniel.vetter@...ll.ch>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Waiman Long <waiman.long@....com>,
Jason Low <jason.low2@....com>,
Ding Tianhong <dingtianhong@...wei.com>,
Thomas Gleixner <tglx@...utronix.de>,
Will Deacon <Will.Deacon@....com>,
Ingo Molnar <mingo@...hat.com>,
Imre Deak <imre.deak@...el.com>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Davidlohr Bueso <dave@...olabs.net>,
Tim Chen <tim.c.chen@...ux.intel.com>,
Terry Rudd <terry.rudd@....com>,
"Paul E. McKenney" <paulmck@...ibm.com>,
Jason Low <jason.low2@...com>,
Chris Wilson <chris@...is-wilson.co.uk>,
Rob Clark <robdclark@...il.com>
Subject: Re: [PATCH -v4 1/8] locking/drm: Kill mutex trickery
On Tue, Oct 18, 2016 at 2:57 PM, Peter Zijlstra <peterz@...radead.org> wrote:
> On Tue, Oct 18, 2016 at 02:48:41PM +0200, Peter Zijlstra wrote:
>> On Fri, Oct 07, 2016 at 04:52:44PM +0200, Peter Zijlstra wrote:
>> > Poking at lock internals is not cool. Since I'm going to change the
>> > implementation this will break, take it out.
>> >
>> > Cc: Daniel Vetter <daniel.vetter@...ll.ch>
>> > Cc: Chris Wilson <chris@...is-wilson.co.uk>
>> > Cc: Rob Clark <robdclark@...il.com>
>> > Signed-off-by: Peter Zijlstra (Intel) <peterz@...radead.org>
>> > ---
>> > drivers/gpu/drm/i915/i915_gem_shrinker.c | 26 +++-----------------------
>> > drivers/gpu/drm/msm/msm_gem_shrinker.c | 23 +++--------------------
>> > 2 files changed, 6 insertions(+), 43 deletions(-)
>>
>> OK, so it appears that i915 changed their locking around and got rid of
>> this thing entirely. Much appreciated Chris!!
>
> Hmm, I might have spoken too soon. My patch conflicted and I seem to
> have read too much in the Changelog of 3b4e896f14b1 ("drm/i915: Remove
> unused no-shrinker-steal").
Once all your locking rework is assembled it might be good to have a
topic branch I could pull in. Both for testing and to handle conflicts
before it goes boom in the merge window ;-) Not necessary ofc, but I
think it'd be useful.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
Powered by blists - more mailing lists