From: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri, 19 Jan 2018 14:46:57 +0000
Subject: drm/i915: Shrink the request kmem_cache on allocation error
Git-commit: f0111b04ff43ec237fb4419f164a7d1ed1d02bcf
Patch-mainline: v4.17-rc1
References: FATE#326289 FATE#326079 FATE#326049 FATE#322398 FATE#326166
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
Acked-by: Petr Tesarik <ptesarik@suse.com>
---
drivers/gpu/drm/i915/i915_gem_request.c | 11 +++++++++++
1 file changed, 11 insertions(+)
--- a/drivers/gpu/drm/i915/i915_gem_request.c
+++ b/drivers/gpu/drm/i915/i915_gem_request.c
@@ -698,6 +698,17 @@ i915_gem_request_alloc(struct intel_engi
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;