Messages in this thread | | | Date | Tue, 10 Oct 2023 10:08:40 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH 00/15] sched: EEVDF and latency-nice and/or slice-attr |
| |
On Thu, Oct 05, 2023 at 01:23:14PM -0500, Youssef Esmat wrote: > On Thu, Oct 5, 2023 at 7:06 AM Peter Zijlstra <peterz@infradead.org> wrote:
> > BAaaBCccccccccBBBAaaBBBAaaBB BBAaaBBBAaaBBBAaaBCccccccccB > > > > > > > > As I wrote before; EVDF has worse lag bounds, but this is not > > insurmountable. The biggest problem that I can see is that of wakeup > > preemption. Currently we allow to preempt when 'current' has reached V > > (RUN_TO_PARITY in pick_eevdf()). > > > > With these rules, when EEVDF schedules C (our large slice task) at t=10 > > above, it is only a little behind C and can be reaily preempted after > > about 2 time units. > > > > However, EVDF will delay scheduling C until much later, see how A and B > > walk far ahead of V until t=36. Only when will we pick C. But this means > > that we're firmly stuck with C for at least 11 time units. A newly > > placed task will be around V and will have no chance to preempt. > > > > Thank you for the detailed analysis! I am still in the process of > digesting everything. > I do have a quick question, this will only be the case if we adjust > C's runtime without adjusting nice value, correct? So it does not > currently apply to the submitted code where the only way to change the > deadline is to also change the nice value and thus how fast/slow > vruntime accumulates. In other words without the sched_runtime > patch[1] we should not run into this scenario, correct? > > [1] https://lore.kernel.org/lkml/20230915124354.416936110@noisy.programming.kicks-ass.net/
Much harder to run into it, but you can still hit it using nice.
d_i = v_i + r_i / w_i
So for very light tasks, the effective v_deadline goes out lots.
And as I wrote yesterday, by delaying scheduling (far) past 0-lag you effectively open up a denial of service window, since new tasks are placed around 0-lag.
Now, nobody will likely care much if very light tasks get horrific treatment, but still, it's there.
| |