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