Re: [PATCH 23/30] sched/fair: handle tick expiry under lazy preemption

[Juri Lelli <juri.lelli@redhat.com>]

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