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. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
