Lazy Preemption Merged Along With Other Scheduler Improvements For Linux 6.13

[ptr1337]

ptr1337 backported it on CachyOS 6.12 kernel.
I'm using his patch for my own kernel BTW, thanks ptr1337.

Yes But only using it right now for the "server" variant, since im not sure, how much desktop will benefit from it. I made some production benchmarks on my machine, but did not see a heavy difference, therefore I kept for the "desktops" kernel preempt=full

I think that needs more playing with ananicy-cpp to put some processes to real time, so that it preempts same as with rt for compositors, games or equal. Would be interesting to play with

[Anux]

Lazy? Looks more like that little penguin took one of mommy's "vitamin" gummies.

And though she's not really ill
There's a little yellow pill
She goes running for the shelter
Of her mother's little helper

[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.

[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.

[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]

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]

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

[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.

[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.

[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.