Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1519703 > unrolled thread

Re: [PATCH -v4 1/8] locking/drm: Kill mutex trickery

Started byDaniel Vetter <daniel.vetter@ffwll.ch>
First post2016-11-11 12:30 +0100
Last post2016-11-14 15:30 +0100
Articles 5 — 3 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: [PATCH -v4 1/8] locking/drm: Kill mutex trickery Daniel Vetter <daniel.vetter@ffwll.ch> - 2016-11-11 12:30 +0100
    Re: [PATCH -v4 1/8] locking/drm: Kill mutex trickery Peter Zijlstra <peterz@infradead.org> - 2016-11-11 12:40 +0100
      Re: [PATCH -v4 1/8] locking/drm: Kill mutex trickery Ingo Molnar <mingo@kernel.org> - 2016-11-12 12:00 +0100
        Re: [PATCH -v4 1/8] locking/drm: Kill mutex trickery Peter Zijlstra <peterz@infradead.org> - 2016-11-14 15:10 +0100
          Re: [PATCH -v4 1/8] locking/drm: Kill mutex trickery Ingo Molnar <mingo@kernel.org> - 2016-11-14 15:30 +0100

#1519703 — Re: [PATCH -v4 1/8] locking/drm: Kill mutex trickery

FromDaniel Vetter <daniel.vetter@ffwll.ch>
Date2016-11-11 12:30 +0100
SubjectRe: [PATCH -v4 1/8] locking/drm: Kill mutex trickery
Message-ID<sCibT-3Ek-1@gated-at.bofh.it>
On Tue, Oct 18, 2016 at 2:57 PM, Peter Zijlstra <peterz@infradead.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@ffwll.ch>
>> > Cc: Chris Wilson <chris@chris-wilson.co.uk>
>> > Cc: Rob Clark <robdclark@gmail.com>
>> > Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.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

[toc] | [next] | [standalone]


#1519714

FromPeter Zijlstra <peterz@infradead.org>
Date2016-11-11 12:40 +0100
Message-ID<sCilz-3Hy-29@gated-at.bofh.it>
In reply to#1519703
On Fri, Nov 11, 2016 at 12:22:02PM +0100, Daniel Vetter wrote:

> 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.

Everything except the trylock_recursive is already in tip/locking/core.

Ingo, is that all there is in that branch?

[toc] | [prev] | [next] | [standalone]


#1520225

FromIngo Molnar <mingo@kernel.org>
Date2016-11-12 12:00 +0100
Message-ID<sCEcp-VK-1@gated-at.bofh.it>
In reply to#1519714
* Peter Zijlstra <peterz@infradead.org> wrote:

> On Fri, Nov 11, 2016 at 12:22:02PM +0100, Daniel Vetter wrote:
> 
> > 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.
> 
> Everything except the trylock_recursive is already in tip/locking/core.
> 
> Ingo, is that all there is in that branch?

It has other bits as well - but I can create a separate topic branch for this, 
which would be c7faee2109f9 plus trylock_recursive().

Could you send a final version of trylock_recursive() patch for me to apply?

Thanks,

	Ingo

[toc] | [prev] | [next] | [standalone]


#1521678

FromPeter Zijlstra <peterz@infradead.org>
Date2016-11-14 15:10 +0100
Message-ID<sDq7o-81N-35@gated-at.bofh.it>
In reply to#1520225
On Sat, Nov 12, 2016 at 11:58:49AM +0100, Ingo Molnar wrote:

> Could you send a final version of trylock_recursive() patch for me to apply?

The latest lives here:

 lkml.kernel.org/r/20161109103813.GN3157@twins.programming.kicks-ass.net

But I would really like someone to actually test that before you stick
it in.

[toc] | [prev] | [next] | [standalone]


#1521691

FromIngo Molnar <mingo@kernel.org>
Date2016-11-14 15:30 +0100
Message-ID<sDqqJ-892-9@gated-at.bofh.it>
In reply to#1521678
* Peter Zijlstra <peterz@infradead.org> wrote:

> On Sat, Nov 12, 2016 at 11:58:49AM +0100, Ingo Molnar wrote:
> 
> > Could you send a final version of trylock_recursive() patch for me to apply?
> 
> The latest lives here:
> 
>  lkml.kernel.org/r/20161109103813.GN3157@twins.programming.kicks-ass.net
> 
> But I would really like someone to actually test that before you stick
> it in.

Agreed ...

Thanks,

	Ingo

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web