[PATCH 2/3] drm/i915: Force kswapd to reclaim our request/object slabs

[Chris Wilson]

The core mm fails to reclaim from RCU deferred frees under mempressure.
This is particularly noticeable for ourselves when running igt on 32b
platforms are our RCU deferred free of requests (and their callbacks)
quickly drain the available GFP_KERNEL (lowmem) and are *not* recovered,
even under oom itself. Try to remedy the lost slabs by inserting an rcu
barrier and forcibly freeing our stale objects under kswapd.

Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
---
 drivers/gpu/drm/i915/i915_gem_shrinker.c | 10 ++++++++++
 1 file changed, 10 insertions(+)

diff --git a/drivers/gpu/drm/i915/i915_gem_shrinker.c b/drivers/gpu/drm/i915/i915_gem_shrinker.c
index 9029ed04879c..2f87c27fb2ac 100644
--- a/drivers/gpu/drm/i915/i915_gem_shrinker.c
+++ b/drivers/gpu/drm/i915/i915_gem_shrinker.c
@@ -382,6 +382,16 @@ i915_gem_shrinker_scan(struct shrinker *shrinker, struct shrink_control *sc)
 
 	shrinker_unlock(i915, unlock);
 
+	/*
+	 * XXX This is mighty incongruous, for are we not doing the core mm's
+	 * job in reclaiming RCU slabs and allocations? No matter, for the
+	 * time being, this is one of the few ways we can ensure that our
+	 * requests and objects, which we marked as SLAB_RECLAIM_ACCOUNT,
+	 * do actually get reclaimed under mempressure.
+	 */
+	if (current_is_kswapd())
+		i915_gem_drain_freed_objects(i915);
+
 	return sc->nr_scanned ? freed : SHRINK_STOP;
 }
 
-- 
2.15.1