[Intel-gfx] [PATCH 4/9] drm/i915/execlists: Suppress redundant preemption

Chris Wilson chris at chris-wilson.co.uk
Wed Jan 30 08:49:56 UTC 2019


Quoting Tvrtko Ursulin (2019-01-30 08:15:56)
> 
> On 29/01/2019 17:02, Chris Wilson wrote:
> > On unwinding the active request we give it a small (limited to internal
> > priority levels) boost to prevent it from being gazumped a second time.
> > However, this means that it can be promoted to above the request that
> > triggered the preemption request, causing a preempt-to-idle cycle for no
> > change. We can avoid this if we take the boost into account when
> > checking if the preemption request is valid.
> > 
> > v2: After preemption the active request will be after the preemptee if
> > they end up with equal priority.
> > 
> > v3: Tvrtko pointed out that this, the existing logic, makes
> > I915_PRIORITY_WAIT non-preemptible. Document this interesting quirk!
> > 
> > v4: Prove Tvrtko was right about WAIT being non-preemptible and test it.
> 
> I thought there would be a simpler solution coming for now. :)

This is the simple version.
 
> In this version WAIT only doesn't preempt if the last rq from a ctx in 
> port0 is already active, otherwise it still preempts.

Sure, no change there then.
 
> Also, by making WAIT not-preempt in this way, we kick the tasklet, 
> right? Only to decide we won't preempt. Or might not, depending on 
> i915_request_started.
> 
> I thought for now we would do something like:
> 
> static inline bool __execlists_need_preempt(int prio, int last)
> {
>         return prio > max(I915_MIN_PREEMPT_PRIORITY, last);
> }

Which is even worse, as now you have two problems... You still have the
false preemptions from before, and some ill-defined behaviour on top.
-Chris


More information about the Intel-gfx mailing list