[Intel-gfx] [PATCH 2/2] drm/i915: Remove the global cache shrink & rcu barrier on allocation failure

Tvrtko Ursulin tvrtko.ursulin at linux.intel.com
Fri Oct 5 08:39:45 UTC 2018


On 05/10/2018 09:03, Chris Wilson wrote:
> Earlier, we reasoned that having idled the gpu under mempressure, that
> would be a good time to trim our request slabs in order to perform the
> next request allocation. We have stopped performing the global operation
> on the device (no idling) and wish to make the allocation failure
> handling more local, so out with the global barrier that may take a long
> time.
> 
> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> Cc: Tvrtko Ursulin <tvrtko.ursulin at intel.com>
> ---
>   drivers/gpu/drm/i915/i915_request.c | 11 -----------
>   1 file changed, 11 deletions(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_request.c b/drivers/gpu/drm/i915/i915_request.c
> index 32bf2c9868bf..c5e40e5f0e65 100644
> --- a/drivers/gpu/drm/i915/i915_request.c
> +++ b/drivers/gpu/drm/i915/i915_request.c
> @@ -657,17 +657,6 @@ i915_request_alloc(struct intel_engine_cs *engine, struct i915_gem_context *ctx)
>   		if (rq)
>   			cond_synchronize_rcu(rq->rcustate);
>   
> -		/*
> -		 * 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(i915->requests);
> -		rcu_barrier(); /* Recover the TYPESAFE_BY_RCU pages */
> -
>   		rq = kmem_cache_alloc(i915->requests, GFP_KERNEL);
>   		if (!rq) {
>   			ret = -ENOMEM;
> 

Wish I was in space...
.
.
.
.
...so no one could hear me scream! :))

Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin at intel.com>

Regards,

Tvrtko


More information about the Intel-gfx mailing list