Re: [PATCH 1/2] drm/i915: Trim the retired request queue after submitting

[Tvrtko Ursulin <tvrtko.ursulin@linux.intel.com>]

On 07/02/2018 08:43, Chris Wilson wrote:
> If we submit a request and see that the previous request on this
> timeline was already signaled, we first do not need to add the
> dependency tracker for that completed request and secondly we know that
> we there is then a large backlog in retiring requests affecting this
> timeline. Given that we just submitted more work to the HW, now would be
> a good time to catch up on those retirements.
> 
> v2: Try to sum up the compromises involved in flushing the retirement
> queue after submission.
> 
> Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
> Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
> Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
> ---
>   drivers/gpu/drm/i915/i915_gem_request.c | 20 ++++++++++++++++++++
>   1 file changed, 20 insertions(+)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_request.c b/drivers/gpu/drm/i915/i915_gem_request.c
> index 794263421aa0..384cb49ae4cc 100644
> --- a/drivers/gpu/drm/i915/i915_gem_request.c
> +++ b/drivers/gpu/drm/i915/i915_gem_request.c
> @@ -1075,6 +1075,26 @@ void __i915_add_request(struct drm_i915_gem_request *request, bool flush_caches)
>   	local_bh_disable();
>   	i915_sw_fence_commit(&request->submit);
>   	local_bh_enable(); /* Kick the execlists tasklet if just scheduled */
> +
> +	/*
> +	 * In typical scenarios, we do not expect the previous request on
> +	 * the timeline to be still tracked by timeline->last_request if it
> +	 * has been completed. If the completed request is still here, that
> +	 * implies that request retirement is a long way behind submission,
> +	 * suggesting that we haven't been retiring frequently enough from
> +	 * the combination of retire-before-alloc, waiters and the background
> +	 * retirement worker. So if the last request on this timeline was
> +	 * already completed, do a catch up pass, flushing the retirement queue
> +	 * up to this client. Since we have now moved the heaviest operations
> +	 * during retirement onto secondary workers, such as freeing objects
> +	 * or contexts, retiring a bunch of requests is mostly list management
> +	 * (and cache misses), and so we should not be overly penalizing this
> +	 * client by performing excess work, though we may still performing
> +	 * work on behalf of others -- but instead we should benefit from
> +	 * improved resource management. (Well, that's the theory at least.)
> +	 */
> +	if (prev && i915_gem_request_completed(prev))
> +		i915_gem_request_retire_upto(prev);
>   }
>   
>   static unsigned long local_clock_us(unsigned int *cpu)
> 

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

Regards,

Tvrtko
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx