Quoting Tvrtko Ursulin (2019-01-09 14:12:46) > From: Tvrtko Ursulin <tvrtko.ursu...@intel.com> > > 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 extracting the shrinking part to __i915_gem_shrink, > wrapped by struct mutex taking i915_gem_shrink. > > At the same time move the runtime pm reference taking to always be in the > usual, before struct mutex, order. > > v2: > * Don't use flags but split i915_gem_shrink into locked and unlocked.
Yes, I do prefer this to passing flags down, but I feel very underwhelmed by it. The fact that the recursive lock exists is the problem and this isn't reducing the problem (imo). I'd rather push the only call to shrinker_lock down to i915_gem_shrink and remove it from shrinker_scan and shrinker_vmap which should be doable in a few patches -- that would get rid of the self-inflicted recursion but still recursing from our callers. -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
