[Intel-gfx] [PATCH] drm/i915/gtt: Replace struct_mutex serialisation for allocation

Chris Wilson chris at chris-wilson.co.uk
Tue Jun 4 11:42:38 UTC 2019


Quoting Joonas Lahtinen (2019-06-04 12:37:03)
> Quoting Chris Wilson (2019-06-03 20:11:30)
> > Instead of relying on the caller holding struct_mutex across the
> > allocation, push the allocation under a tree of spinlocks stored inside
> > the page tables. Not only should this allow us to avoid struct_mutex
> > here, but it will allow multiple users to lock independent ranges for
> > concurrent allocations, and operate independently. This is vital for
> > pushing the GTT manipulation into a background thread where dependency
> > on struct_mutex is verboten, and for allowing other callers to avoid
> > struct_mutex altogether.
> > 
> > Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> > Cc: Matthew Auld <matthew.auld at intel.com>
> > Cc: Mika Kuoppala <mika.kuoppala at intel.com>
> 
> <SNIP>
> 
> > @@ -1684,9 +1752,7 @@ static void gen6_ppgtt_clear_range(struct i915_address_space *vm,
> >  
> >                 num_entries -= count;
> >  
> > -               GEM_BUG_ON(count > pt->used_ptes);
> 
> This seems to be lost, and it's definitely a valid check, still.
> 
> With that retained, this is:
> 
> Reviewed-by: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
> 
> Operations *_ppgtt_set_* + atomic_inc(used_*) and *_ppgtt_set_*(scratch) +
> atomic_dec() appear repetitive, but as they're for each different level,
> a helper might or might not make it cleaner.

Mika is working on refactoring the layers, so I'm hoping that mostly
falls out in the wash. Or at least becomes easier to do so.
-Chris


More information about the Intel-gfx mailing list