On Wed, 2017-11-08 at 09:44 +0000, Chris Wilson wrote: > The handling of contexts are peculiar. Instead of tieing their vma to > activity, we pin the context. This means that we cannot simply unbind > the context object itself at will (which would normally cause us to wait > for the vma to be idle), but must manually idle the GPU and retire > requests first. > > A consequence of this peculiarity is when doing a last desperate attempt > to recover memory. If the memory is tied up inside active context > objects, we will fail to recover any memory simply by trying to unbind > the objects without first doing a wait-for-idle. > > A side-effect of removing the call to shrinker_lock_uninterruptible() > from i915_gem_shrinker_oom() was that we removed an unlocked > wait-for-idle, and so lost the "natural" shrinkage of context objects. > By replacing that with a locked wait from inside i915_gem_shrink(), we > not only replace it with the ability to recover all context objects, but > do so for all i915_gem_shrink_all() callers. > > v2: Switching requires request allocation, which is not permitted from > inside the shrinker as it only uses ordinary allocations. > > References: https://bugs.freedesktop.org/show_bug.cgi?id=102936 > Fixes: f2123818ffad ("drm/i915: Move dev_priv->mm.[un]bound_list to its own lock") > Signed-off-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> > Cc: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> Reviewed-by: Joonas Lahtinen <joonas.lahtinen@xxxxxxxxxxxxxxx> Regards, Joonas -- Joonas Lahtinen Open Source Technology Center Intel Corporation _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
