[Intel-gfx] [PATCH] drm/i915/execlists: Don't merely skip submission if maybe timeslicing

[Chris Wilson]

Quoting Tvrtko Ursulin (2019-10-18 10:50:55)
> 
> On 17/10/2019 10:52, Chris Wilson wrote:
> > Normally, we try and skip submission if ELSP[1] is filled. However, we
> > may desire to enable timeslicing due to the queue priority, even if
> > ELSP[1] itself does not require timeslicing. That is the queue is equal
> > priority to ELSP[0] and higher priority then ELSP[1]. Previously, we
> > would wait until the context switch to preempt the current ELSP[1], but
> > with timeslicing, we want to preempt ELSP[0] and replace it with the
> > queue.
> 
> Why we want to preempt ELSP[0] if the statement is queue is not higher 
> priority from it?

It is of equal priority, the desire is to alternate.

ELSP[1].prio < ELSP[0].prio
Q.prio = ELSP[0].prio (=> Q.prio > ELSP[1].prio)

Ergo, we would like to replace ELSP[1] with Q, and then alternate between
the two ELSP[]. What actually happens is we enable the timeslice and
promote Q into ELSP[0] with ELSP[1] taking the next highest priority
task (maybe the old ELSP[0]).
 
> > +static inline bool need_preempt(int prio, int active)
> > +{
> > +     /*
> > +      * Allow preemption of low -> normal -> high, but we do
> > +      * not allow low priority tasks to preempt other low priority
> > +      * tasks under the impression that latency for low priority
> > +      * tasks does not matter (as much as background throughput),
> > +      * so kiss.
> > +      */
> > +     return prio >= max(I915_PRIORITY_NORMAL, active);
> 
> Is this the same as the current:
> 
>    return prio > max(I915_PRIORITY_NORMAL - 1, active);
> 
> Hm no, it now allows for high prio tasks to preempt equal high prio.
> 
> So it will kick the tasklet and dequeue will then decide no to 
> need_preempt after all. Where it is the catch? Okay catch is in the 
> other execlist_dequeue hunk - that it will now enable the timeslice timer.
> 
> I have to say it is getting very difficult to tie everything together. I 
> wish for a simpler design with more centralized "magic" on hadling 
> priorities etc.

How more central can we get? Not do the tasklet_schedule filtering at
all. That's the only real wart at the moment. Then i915_schedule.c is
just DAG maintenance.
-Chris