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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
