[Intel-gfx] [PATCH 04/11] drm/i915: Make request allocation caches global

[Chris Wilson]

Quoting Tvrtko Ursulin (2019-02-27 14:17:25)
> 
> On 27/02/2019 10:44, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2019-02-27 10:29:43)
> >>
> >> On 26/02/2019 10:23, Chris Wilson wrote:
> >>> As kmem_caches share the same properties (size, allocation/free behaviour)
> >>> for all potential devices, we can use global caches. While this
> >>> potential has worse fragmentation behaviour (one can argue that
> >>> different devices would have different activity lifetimes, but you can
> >>> also argue that activity is temporal across the system) it is the
> >>> default behaviour of the system at large to amalgamate matching caches.
> >>>
> >>> The benefit for us is much reduced pointer dancing along the frequent
> >>> allocation paths.
> >>>
> >>> v2: Defer shrinking until after a global grace period for futureproofing
> >>> multiple consumers of the slab caches, similar to the current strategy
> >>> for avoiding shrinking too early.
> >>
> >> I suggested to call i915_globals_park directly from __i915_gem_park for
> >> symmetry with how i915_gem_unpark calls i915_globals_unpark.
> >> i915_globals has it's own delayed setup so I don't think it benefits
> >> from the double indirection courtesy of being called from shrink_caches.
> > 
> > I replied I left that change until a later patch after the final
> > conversions. Mostly so that we had a standalone patch to revert if the
> > rcu_work turns out badly. In this patch, it was to be the simple
> > translation over to global_shrink, except you asked for it to be truly
> > global and so we needed another layer of counters.
> 
> It's a hard sell I think. Because why even have rcu work now in this 
> case? You could make i915_globals_park just shrink if active counter 
> dropped to zero. I don't see a benefit in a temporary asymmetric solution.

I did do just that in v1!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
-Chris