[Intel-gfx] [PATCH] drm/i915: More proactive timeline retirement before new requests

[Chris Wilson]

Quoting Chris Wilson (2020-01-13 14:07:15)
> @@ -1344,28 +1330,6 @@ void i915_request_add(struct i915_request *rq)
>         __i915_request_queue(rq, &attr);
>         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_request_completed(prev) &&
> -           rcu_access_pointer(prev->timeline) == tl)
> -               i915_request_retire_upto(prev);

Hmm, the argument in favour of retiring after submitting the request is still
reasonable, i.e. try not to add latency before the next request.
-Chris