Quoting Tvrtko Ursulin (2019-01-07 14:00:25) > > On 07/01/2019 11:54, Chris Wilson wrote: > > Ignore trying to shrink from i915 if we fail to acquire the struct_mutex > > in the shrinker while performing direct-reclaim. The trade-off being > > (much) lower latency for non-i915 clients at an increased risk of being > > unable to obtain a page from direct-reclaim without hitting the > > oom-notifier. The proviso being that we still keep trying to hard > > obtain the lock for kswapd so that we can reap under heavy memory > > pressure. > > > > v2: Taint all mutexes taken within the shrinker with the struct_mutex > > subclass as an early warning system, and drop I915_SHRINK_ACTIVE from > > vmap to reduce the number of dangerous paths. We also have to drop > > I915_SHRINK_ACTIVE from oom-notifier to be able to make the same claim > > that ACTIVE is only used from outside context, which fits in with a > > longer strategy of avoiding stalls due to scanning active during > > shrinking. > > Oom notifier is not always the outside context? oom-notifier is the final death throes of direct reclaim. > > @@ -2255,8 +2256,7 @@ int i915_gem_gtt_prepare_pages(struct drm_i915_gem_object *obj, > > } while (i915_gem_shrink(to_i915(obj->base.dev), > > obj->base.size >> PAGE_SHIFT, NULL, > > I915_SHRINK_BOUND | > > - I915_SHRINK_UNBOUND | > > - I915_SHRINK_ACTIVE)); > > + I915_SHRINK_UNBOUND)); > > > > Why this change? gtt_prepare_pages is called at the end of obj->ops->get_pages() which is not guaranteed to be outside of struct_mutex (yet). So I dropped the ACTIVE here as part of the claim that ACTIVE is only used from kswapd (or at known idle times such as i915_gem_freeze where I can handwave that ACTIVE is meaningless). -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
