From: Chris Wilson Date: Fri, 19 Jan 2018 14:46:57 +0000 (+0000) Subject: drm/i915: Shrink the request kmem_cache on allocation error X-Git-Tag: v4.19~298^2~46^2~780 X-Git-Url: http://review.tizen.org/git/?a=commitdiff_plain;h=f0111b04ff43ec237fb4419f164a7d1ed1d02bcf;p=platform%2Fkernel%2Flinux-rpi.git 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: Chris Wilson Cc: Tvrtko Ursulin Reviewed-by: Tvrtko Ursulin Link: https://patchwork.freedesktop.org/patch/msgid/20180119144657.22606-1-chris@chris-wilson.co.uk --- diff --git a/drivers/gpu/drm/i915/i915_gem_request.c b/drivers/gpu/drm/i915/i915_gem_request.c index 72bdc20..a0f451b 100644 --- a/drivers/gpu/drm/i915/i915_gem_request.c +++ b/drivers/gpu/drm/i915/i915_gem_request.c @@ -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;