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