drm/i915/gem: Unpin idle contexts from kswapd reclaim
authorChris Wilson <chris@chris-wilson.co.uk>
Wed, 8 Jul 2020 17:37:45 +0000 (18:37 +0100)
committerChris Wilson <chris@chris-wilson.co.uk>
Wed, 8 Jul 2020 21:05:49 +0000 (22:05 +0100)
commit09137e94543761154f464433c019d51d6ac32fcf
treed317a5c42039839ac06b4708394ff9cb595cc38f
parenta00eda7d8996803320bc63c574ee78f8a2fb72ee
drm/i915/gem: Unpin idle contexts from kswapd reclaim

We removed retiring requests from the shrinker in order to decouple the
mutexes from reclaim in preparation for unravelling the struct_mutex.
The impact of not retiring is that we are much less agressive in making
global objects available for shrinking, as such objects remain pinned
until they are flushed by a heartbeat pulse following the last retired
request along their timeline. In order to ensure that pulse occurs in
time for memory reclamation, we should kick it from kswapd.

The catch is that we have added some flush_work() into the retirement
phase (to ensure that we reach a global idle in a timely manner), but
these flush_work() are not eligible (i.e do not belong to WQ_MEM_RELCAIM)
for use from inside kswapd. To avoid flushing those workqueues, we teach
the retirer not to do so unless we are actually waiting, and only do the
plain retire from inside the shrinker.

Note that for execlists, we already retire completed contexts as they
are scheduled out, so it should not be keeping global state
unnecessarily pinned. The legacy ringbuffer however...

References: 9e9539800dd4 ("drm/i915: Remove waiting & retiring from shrinker paths")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Matthew Auld <matthew.auld@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20200708173748.32734-1-chris@chris-wilson.co.uk
drivers/gpu/drm/i915/gem/i915_gem_shrinker.c
drivers/gpu/drm/i915/gt/intel_gt_requests.c