[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