Lazy Preemption Merged Along With Other Scheduler Improvements For Linux 6.13

[Mitch]

EEVDF doesn't by itself cause any more or less context switches than any other scheduler. A better scheduler can just do a better job of selecting which task to run next (well, ignoring things like moving tasks over to another cpu etc. which would cause an interrupt (IPI) and thus a potential preemption on that CPU etc.). I think the main advantage of EEVDF over CFS is just that it's better at choosing the next task, leading to less stutter because things like pipewire or whatever is responsible for moving the cursor on the screen etc. gets access to the cpu more regularly.

Now it may be that these choices about which process to run leads to more context switches, if EEVDF more often selects some process that uses a tiny amount of CPU then goes to sleep again (like updating the mouse cursor position on the screen etc.), necessitating the scheduler to run again to select something else.

So if I understand correctly, a kernel with EEVDF and Lazy PreEmption ought have a net effect of less stuttering and latency of things like audio, UI, especially under more conditions, such as high load and reduced operating speeds (low powered devices).

[waxhead]

EEVDF doesn't by itself cause any more or less context switches than any other scheduler....

....Now it may be that these choices about which process to run leads to more context switches, if EEVDF more often selects some process that uses a tiny amount of CPU then goes to sleep again...

Thanks for the answer, but this is exactly my point and why I asked about how the lazy patch potentially might trigger this condition (which I **assume** would not be the case with CFS to the same extent).

Not sure how much a context switch "cost" these days, or if this time cost is part of the lag calculation in EEVDF somehow, but I can imagine it won't matter much unless the CPU is fully loaded anyway, but it is still interesting.

[sophisticles]

In case someone wonders what this lazy preempt thing is, I wrote up an explanation in the other thread at https://www.phoronix.com/forums/foru...21#post1504521

I'm too lazy to read it.

[jabl]

Understood, but assuming the EEVDF does what it is supposed to e.g. smoothing out lag, would not this in theory "chop up" the processing, resulting in more potential context switches on a less that fully loaded system? Or in other words less throughout and possibly even more latency? Something the CFS would not care so much about. I admit to not understanding the fine details here but that's how it seems to me. Maybe I'm wrong.

EEVDF doesn't by itself cause any more or less context switches than any other scheduler. A better scheduler can just do a better job of selecting which task to run next (well, ignoring things like moving tasks over to another cpu etc. which would cause an interrupt (IPI) and thus a potential preemption on that CPU etc.). I think the main advantage of EEVDF over CFS is just that it's better at choosing the next task, leading to less stutter because things like pipewire or whatever is responsible for moving the cursor on the screen etc. gets access to the cpu more regularly.

Now it may be that these choices about which process to run leads to more context switches, if EEVDF more often selects some process that uses a tiny amount of CPU then goes to sleep again (like updating the mouse cursor position on the screen etc.), necessitating the scheduler to run again to select something else.

[waxhead]

It's kind of orthogonal. After the current thread has been preempted, the scheduler code (EEVDF, CFS, whatever) is run to decide which thread to switch to.

EDIT: That is to say, the scheduler code per se doesn't decide when to preempt, it only decides what to do after preemption has already happened.

Understood, but assuming the EEVDF does what it is supposed to e.g. smoothing out lag, would not this in theory "chop up" the processing, resulting in more potential context switches on a less that fully loaded system? Or in other words less throughout and possibly even more latency? Something the CFS would not care so much about. I admit to not understanding the fine details here but that's how it seems to me. Maybe I'm wrong.

[davidbepo]

AFAIU the PREEMPT_LAZY work was inspired by something roughly similar that was part of (or experimented with in) the PREEMPT_RT tree (not sure if it was merged when PREEMPT_RT became part of mainline). So yes, it's definitely possible.

However, unfortunately this does not mean that PREEMPT_RT could run non-RT tasks as quickly as the other PREEMPT_* modes. In the name of minimizing the time the kernel is in a non-preemptible state, the PREEMPT_RT mode changes a lot of things, like converting most spinlocks (which are non-preemptible) to mutexes (which are sleepable, that is, preemptible), converting all interrupt handlers to run in threads, etc. All this helps with achieving deterministic latency, but come at a definitive cost in throughput also for non-RT tasks.

thanks again, so while my idea is possible and likely good, it woulnt be a perfect win, got it

[jabl]

it gives me an idea tho, could preempt_rt be combined with preempt_lazy? i assume its possible since rt is code changes, not model
i think this could give an scenario where you can have both RT and full perf just by setting tasks priorities right

AFAIU the PREEMPT_LAZY work was inspired by something roughly similar that was part of (or experimented with in) the PREEMPT_RT tree (not sure if it was merged when PREEMPT_RT became part of mainline). So yes, it's definitely possible.

However, unfortunately this does not mean that PREEMPT_RT could run non-RT tasks as quickly as the other PREEMPT_* modes. In the name of minimizing the time the kernel is in a non-preemptible state, the PREEMPT_RT mode changes a lot of things, like converting most spinlocks (which are non-preemptible) to mutexes (which are sleepable, that is, preemptible), converting all interrupt handlers to run in threads, etc. All this helps with achieving deterministic latency, but come at a definitive cost in throughput also for non-RT tasks.

[davidbepo]

In case someone wonders what this lazy preempt thing is, I wrote up an explanation in the other thread at https://www.phoronix.com/forums/foru...21#post1504521

very informative read, thanks
it gives me an idea tho, could preempt_rt be combined with preempt_lazy? i assume its possible since rt is code changes, not model
i think this could give an scenario where you can have both RT and full perf just by setting tasks priorities right

[jabl]

That was a good read. Just curious - what would the impact of lazy be on EEVDF vs CFS (or even the NEST approach)? Not that it matters much since CFS is in the history books but I am still curious.

It's kind of orthogonal. After the current thread has been preempted, the scheduler code (EEVDF, CFS, whatever) is run to decide which thread to switch to.

EDIT: That is to say, the scheduler code per se doesn't decide when to preempt, it only decides what to do after preemption has already happened.

[waxhead]

In case someone wonders what this lazy preempt thing is, I wrote up an explanation in the other thread at https://www.phoronix.com/forums/foru...21#post1504521

That was a good read. Just curious - what would the impact of lazy be on EEVDF vs CFS (or even the NEST approach)? Not that it matters much since CFS is in the history books but I am still curious.