drm/i915: Prefer random replacement before eviction search
authorChris Wilson <chris@chris-wilson.co.uk>
Wed, 11 Jan 2017 11:23:12 +0000 (11:23 +0000)
committerChris Wilson <chris@chris-wilson.co.uk>
Wed, 11 Jan 2017 12:28:37 +0000 (12:28 +0000)
commit606fec956c0e8c53bbad19c918e43147daa76429
tree4ed3435ca41bdbf27bf571235825ce4302eb531c
parent625d988acc28f3fe1d44f3798426561c17387a59
drm/i915: Prefer random replacement before eviction search

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: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20170111112312.31493-3-chris@chris-wilson.co.uk
drivers/gpu/drm/i915/i915_gem_gtt.c