Messages in this thread | ![/](/images/icornerl.gif) | | Date | Thu, 29 Feb 2024 16:28:20 -0800 | From | "Paul E. McKenney" <> | Subject | Re: [PATCH 23/30] sched/fair: handle tick expiry under lazy preemption |
| |
On Thu, Feb 29, 2024 at 03:54:42PM -0800, Ankur Arora wrote: > > Juri Lelli <juri.lelli@redhat.com> writes: > > > 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 > > Yeah, that's kind of where I'm thinking of getting to. Be lazy so long > as we don't violate guarantees. > > > 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. > > Yeah, the difference between preempt=none and preempt=voluntary is > looking narrower and narrower, and maybe a bit artificial in that > there seem to be very few cases where the two models would actually > differ in behaviour.
If it turns out that cond_resched() and the preemption points in might_sleep() really can be dispensed with, then there would be little difference between them. But that is still "if". ;-)
Thanx, Paul
> Thanks > Ankur > > >> Thanks for the review, btw. > > > > Sure. Thanks for working on this actually! :) > > > > Best, > > Juri
| ![\](/images/icornerr.gif) |