Commit f0111b04 authored by Chris Wilson's avatar Chris Wilson

drm/i915: Shrink the request kmem_cache on allocation error

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: default avatarChris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: default avatarTvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20180119144657.22606-1-chris@chris-wilson.co.uk
parent bd724318
......@@ -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;
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment