[Intel-gfx] [PATCH v2 1/2] drm/i915/execlists: Suppress preempting self

Chris Wilson chris at chris-wilson.co.uk
Thu Jan 24 15:07:29 UTC 2019


Quoting Chris Wilson (2019-01-24 14:40:40)
> Quoting Tvrtko Ursulin (2019-01-24 14:18:54)
> > 
> > On 23/01/2019 17:44, Chris Wilson wrote:
> > > +     /*
> > > +      * If the inflight context did not trigger the preemption, then maybe
> > > +      * it was the set of queued requests? Pick the highest priority in
> > > +      * the queue (the first active priolist) and see if it deserves to be
> > > +      * running instead of ELSP[0].
> > > +      *
> > > +      * The highest priority request in the queue can not be either
> > > +      * ELSP[0] or ELSP[1] as, thanks again to PI, if it was the same
> > > +      * context, it's priority would not exceed ELSP[0] aka last_prio.
> > > +      */
> > > +     return queue_prio(&engine->execlists) > last_prio;
> > 
> > Could we avoid this check if we only knew the current/latest priority of 
> > ctx in port0? Submitted or not, depending on our policy. But is we see 
> > that queue_priority == port0->ctx->priority we can avoid preempting 
> > itself. I guess that could be defeated by a priority ctx set param after 
> > submission but do we care?
> 
> It's upset because at this point we are no longer certain that
> execlists->queue_priority refers to anything. We may have been trying to
> schedule a preemption point on behalf of a request that has long since
> completed.

Or even run on an entirely different engine for veng.
-Chris


More information about the Intel-gfx mailing list