Re: [Intel-gfx] [PATCH 02/23] drm/i915/gem: Split the context's obj:vma lut into its own mutex

2020-07-02 Thread Andi Shyti
Hi Chris, > @@ -1312,11 +1314,11 @@ static int set_ppgtt(struct drm_i915_file_private > *file_priv, > if (vm == rcu_access_pointer(ctx->vm)) > goto unlock; > > + old = __set_ppgtt(ctx, vm); > + > /* Teardown the existing obj:vma cache, it will have to be rebuilt. *

Re: [Intel-gfx] [PATCH 02/23] drm/i915/gem: Split the context's obj:vma lut into its own mutex

2020-07-02 Thread Chris Wilson
Quoting Andi Shyti (2020-07-02 23:09:44) > Hi Chris, > > > @@ -1312,11 +1314,11 @@ static int set_ppgtt(struct drm_i915_file_private > > *file_priv, > > if (vm == rcu_access_pointer(ctx->vm)) > > goto unlock; > > > > + old = __set_ppgtt(ctx, vm); > > + > > /* Teard

[Intel-gfx] [PATCH 02/23] drm/i915/gem: Split the context's obj:vma lut into its own mutex

2020-07-02 Thread Chris Wilson
Rather than reuse the common ctx->mutex for locking the execbuffer LUT, split it into its own lock to avoid being taken [as part of ctx->mutex] at inappropriate times. In particular to avoid the inversion from taking the timeline->mutex for the whole execbuf submission in the next patch. Signed-of