[Bug 102936] [IGT] gem_ctx_thrash single test assertion failure on function gem_set_domain

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=102936

--- Comment #3 from Chris Wilson <chris at chris-wilson.co.uk> ---
commit 1ab22356b37ab08a391d6f007fda4c822bef9fb5
Author: Chris Wilson <chris at chris-wilson.co.uk>
Date:   Tue Nov 7 22:06:56 2017 +0000

    drm/i915: Prune the reservation shared fence array

    The shared fence array is not autopruning and may continue to grow as an
    object is shared between new timelines. Take the opportunity when we
    think the object is idle (we have to confirm that any external fence is
    also signaled) to decouple all the fences.

    We apply a similar trick after waiting on an object, see commit
    e54ca9774777 ("drm/i915: Remove completed fences after a wait")

    v2: No longer need to handle the batch pool as a special case.
    v3: Need to trylock from within i915_vma_retire as this may be called
    form the shrinker - and we may later try to allocate underneath the
    reservation lock, so a deadlock is possible.

    References: https://bugs.freedesktop.org/show_bug.cgi?id=102936
    Fixes: d07f0e59b2c7 ("drm/i915: Move GEM activity tracking into a common
struct reservation_object")
    Fixes: 80b204bce8f2 ("drm/i915: Enable multiple timelines")
    Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
    Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
    Link:
https://patchwork.freedesktop.org/patch/msgid/20171107220656.5020-1-chris@chris-wilson.co.uk
    Reviewed-by: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>

commit 2f6a3783833dde63f1c08982943a8b2229b97afb
Author: Chris Wilson <chris at chris-wilson.co.uk>
Date:   Wed Nov 8 09:44:00 2017 +0000

    drm/i915: Idle the GPU before shinking everything

    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 at chris-wilson.co.uk>
    Cc: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>
    Link:
https://patchwork.freedesktop.org/patch/msgid/20171108094400.1386-1-chris@chris-wilson.co.uk
    Reviewed-by: Joonas Lahtinen <joonas.lahtinen at linux.intel.com>

should help a lot. Still expect that this test (but not this subtest) will fail
if you let it run long enough.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/intel-gfx-bugs/attachments/20171108/9df12625/attachment-0001.html>