Messages in this thread | | | Date | Thu, 29 Feb 2024 10:33:16 +0100 | From | Juri Lelli <> | Subject | Re: [PATCH 23/30] sched/fair: handle tick expiry under lazy preemption |
| |
On 28/02/24 22:43, Ankur Arora wrote: > Juri Lelli <juri.lelli@redhat.com> writes:
..
> > For deadline we call resched_curr_tick() from the throttle part of > > update_curr_dl_se() if the dl_se happens to not be the leftmost anymore, > > so in this case I believe we really want to reschedule straight away and > > not wait for the second time around (otherwise we might be breaking the > > new leftmost tasks guarantees)? > > Yes, agreed, this looks like it breaks the deadline invariant for both > preempt=none and preempt=voluntary. > > For RT, update_curr_rt() seems to have a similar problem if the task > doesn't have RUNTIME_INF. > > Relatedly, do you think there's a similar problem when switching to > a task with a higher scheduling class? > (Related to code is in patch 25, 26.) > > For preempt=voluntary, wakeup_preempt() will do the right thing, but
Right.
> for preempt=none, we only reschedule lazily so the target might > continue to run until the end of the tick.
Hummm, not sure honestly, but I seem to understand that with preempt=none we want to be super conservative wrt preemptions, so maybe current behavior (1 tick of laziness) is OK? Otherwise what would be the difference wrt preempt=voluntary from a scheduler pow? Yes, it might break deadline guarantees, but if you wanted to use preempt=none maybe there is a strong reason for it, I'm thinking.
> Thanks for the review, btw.
Sure. Thanks for working on this actually! :)
Best, Juri
| |