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