[Intel-gfx] [PATCH 08/31] drm/i915: Move rate-limiting request retire to after submission

[Chris Wilson]

Quoting Tvrtko Ursulin (2018-06-27 14:28:08)
> 
> On 27/06/2018 12:16, Chris Wilson wrote:
> > Quoting Tvrtko Ursulin (2018-06-27 11:57:39)
> >> Cost benefit? Is it really so interesting to keep tweaking this? I feel
> >> like I can stamp an r-b with the "yeah whatever" approach.. but the
> >> commit doesn't say what we gain to explain why it is useful to spend
> >> time reviewing it.
> > 
> > The true cost was the contention the earlier retirement was causing with
> > the still inflight ELSP. The cost of that contention is less with the
> > current series, but the implication was made.
> 
> What kind of contention? On the timeline lock? How can it be less to 
> contention to retire all completed requests versus only the oldest and 
> previous?

The problem is how frequently we couldn't retire the oldest, it started
off with a spinwait for the CSB event (since we had the breadcrumb, knew
an arbitration point was coming up, it shouldn't take long, right?).
Yes, in general, contention on the timeline.lock is something to be
concerned about as it shows up frequently on the throughput profiles
(and I'm already looking at how we might split the queue into its own
lock to see if that helps). But I also have to make sure I weight
latency just as heavily as, if not more, throughput.
-Chris