On 03/01/2019 12:29, Chris Wilson wrote:
Quoting Tvrtko Ursulin (2019-01-03 12:23:26)
From: Tvrtko Ursulin <tvrtko.ursulin@xxxxxxxxx>
In two codepaths internal to the shrinker we know we will end up taking
the resursive mutex path.
It instead feels more elegant to avoid this altogether and not call
mutex_trylock_recursive in those cases.
We achieve this by adding a new I915_SHRINK_LOCKED flag which gets passed
to i915_gem_shrink by the internal callers.
Since we reach here from many paths with struct_mutex either locked or
unlocked, special casing one such seems silly. Especially when removing
struct_mutex from here entirely is within our grasp.
Hm, for me it is silly that we rely on mutex_trylock_recursive to handle
what the code clearly knows. Would you be happy with the
__i915_gem_shrink which does no locking, and i915_gem_shrink wraps with
locking, approach instead?
Regards,
Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
