• Chris Wilson's avatar
    drm/i915: Prefer random replacement before eviction search · 606fec95
    Chris Wilson authored
    Performing an eviction search can be very, very slow especially for a
    range restricted replacement. For example, a workload like
    gem_concurrent_blit will populate the entire GTT and then cause aperture
    thrashing. Since the GTT is a mix of active and inactive tiny objects,
    we have to search through almost 400k objects before finding anything
    inside the mappable region, and as this search is required before every
    operation performance falls off a cliff.
    
    Instead of performing the full search, we do a trial replacement of the
    node at a random location fitting the specified restrictions. We lose
    the strict LRU property of the GTT in exchange for avoiding the slow
    search (several orders of runtime improvement for gem_concurrent_blit
    4KiB-global-gtt, e.g. from 5000s to 20s). The loss of LRU replacement is
    (later) mitigated firstly by only doing replacement if we find no
    freespace and secondly by execbuf doing a PIN_NONBLOCK search first before
    it starts thrashing (i.e. the random replacement will only occur from the
    already inactive set of objects).
    
    v2: Ascii-art, and check preconditionst
    v3: Rephrase final sentence in comment to explain why we don't bother
    with if (i915_is_ggtt(vm)) for preferring random replacement.
    Signed-off-by: default avatarChris Wilson <chris@chris-wilson.co.uk>
    Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
    Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
    Reviewed-by: default avatarJoonas Lahtinen <joonas.lahtinen@linux.intel.com>
    Link: http://patchwork.freedesktop.org/patch/msgid/20170111112312.31493-3-chris@chris-wilson.co.uk
    606fec95
i915_gem_gtt.c 100 KB