drm/i915: Shrink the request kmem_cache on allocation error
authorChris Wilson <chris@chris-wilson.co.uk>
Fri, 19 Jan 2018 14:46:57 +0000 (14:46 +0000)
committerChris Wilson <chris@chris-wilson.co.uk>
Fri, 19 Jan 2018 21:13:38 +0000 (21:13 +0000)
If we fail to allocate a new request, make sure we recover the pages
that are in the process of being freed by inserting an RCU barrier.

v2: Comment before the shrink and barrier in the error path.

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180119144657.22606-1-chris@chris-wilson.co.uk
drivers/gpu/drm/i915/i915_gem_request.c

index 72bdc20..a0f451b 100644 (file)
@@ -696,6 +696,17 @@ i915_gem_request_alloc(struct intel_engine_cs *engine,
                if (ret)
                        goto err_unreserve;
 
+               /*
+                * We've forced the client to stall and catch up with whatever
+                * backlog there might have been. As we are assuming that we
+                * caused the mempressure, now is an opportune time to
+                * recover as much memory from the request pool as is possible.
+                * Having already penalized the client to stall, we spend
+                * a little extra time to re-optimise page allocation.
+                */
+               kmem_cache_shrink(dev_priv->requests);
+               rcu_barrier(); /* Recover the TYPESAFE_BY_RCU pages */
+
                req = kmem_cache_alloc(dev_priv->requests, GFP_KERNEL);
                if (!req) {
                        ret = -ENOMEM;