New EEVDF Linux Scheduler Patches Make It Functionally "Complete"

[Quackdoc]

I know there is third party implementations that do it, but imho it should be built into desktops that they somehow inform the scheduler of the current focussed application so that it can receive priority.

Yes and no. I believe a compositor should provide the tools needed to do this, but leave it up to userland tooling to set it up right. I believe this is how S76 is planning it with cosmic?

[pong]

Great, but will my system still freeze under heavy load?

Under heavy load my system freezes to the point that I can't move my mouse cursor, I cannot switch to another virtual terminal, and I cannot kill the offending process. All I can do is wait or REISUB.

Yeah, same here. Notably also OOM / low memory cases as well.

I had high hopes for some of the touted better scheduler / load responsiveness etc. stuff actually handling some of the typical desktop-user bad-cases but apparently not IME so far.

All it'd take is either ex-post-facto (or ab initio!) "de-nice-ing" (et. al.) memory / CPU hog processes to be more likely to swap or schedule at lower priority than interactive terminals, lightweight persistent desktop stuff you probably need / want to work as a priority, etc.

Maybe a bit of proactive monitoring as to the way your processes / programs are using resources and looking out for actual / impending bad cases and prompting the user for a preferable strategy (kill / restart / suspend job, deprioritize more, whatever) before / unless it gets so bad interactivity is just gone at which point it should at least maintain THAT.

It almost seems like wrt. things like errant browsers the best thing would be some kind of sandbox / container / configuration where they just HAVE to stay within a predefined RAM / CPU limit no matter what. If they have to swap (without affecting the rest of the system!) stuff to keep that, great, but in no way do I want a browser taking more than 50% of my CPU or 30% of my RAM e.g. Perhaps quotas / cgroups / something gives something closer to that choice without full virtualization (which itself wouldn't be bad other than the GPU / windowing fiascos).

[timrichardson]

Great, but will my system still freeze under heavy load?

Under heavy load my system freezes to the point that I can't move my mouse cursor, I cannot switch to another virtual terminal, and I cannot kill the offending process. All I can do is wait or REISUB.

That sounds like out of ram rather than CPU. MGLRU should have made that much better for you. Look into your swap settings and make sure your kernel has activated MGLRU.

[Quackdoc]

That sounds like out of ram rather than CPU. MGLRU should have made that much better for you. Look into your swap settings and make sure your kernel has activated MGLRU

it was very common, (and somewhat still is) for the desktop to freeze when the CPU time is taken. a good example of this is CFS + any wayland compositor, They will lock up hard and occasionally just out right crash programs due to wayland messages building up and needing to be killed.

[arighi]

Massive +1, I've been using scx_lavd while gaming on my ryzen 2600, the performance difference when im running updates from the AUR is quite literally 30~fps to 55fps (for some reason it will never get to 60fps even when no load, but sits comfortably close to it) Rustland hasn't been super useful to me.

Can you provide more details about your specific workload / game? I'd be interested to reproduce it and see if we can improve rustland also for this particular case (maybe you could also open a new issue at https://github.com/sched-ext/scx/issues if you can). Thanks!

[Quackdoc]

Can you provide more details about your specific workload / game? I'd be interested to reproduce it and see if we can improve rustland also for this particular case (maybe you could also open a new issue at https://github.com/sched-ext/scx/issues if you can). Thanks!

sure, I was testing Warframe at the time (installed via steam on arch) + a cargo compile, cosmic-applets to be specific https://github.com/pop-os/cosmic-applets. I can try and test other games too. I should have time on saturday to do more thorough testing, Ill try and make a ticket then. Also worth mentioning I have a intel a380 I game on running on cosmic-comp, the NVMe its installed on is running bcachefs, which may be an issue as per https://github.com/sched-ext/scx/issues/96

[Jakobson]

He seems to be rather angry. Whether you like systemd or not, it seems to have no relevance at all regarding the stability of his patches. The other wording like "puking all over the place" reinforces that impression.

I'd much rather learn what "Without something like this EEVDF will simply not work right" means specifically, given that it has been merged without it.

The patches have [RFC] in their subject. I doubt the patches have been merged anywhere.

[npwx]

The patches have [RFC] in their subject. I doubt the patches have been merged anywhere.

EEVDF has been merged, and apparently, it "will simply not work right" without the *new* patches.

[kiffmet]

Yeah, same here. Notably also OOM / low memory cases as well. (…)

zswap w/ z3fold and zstd compression, 33% max pool percent, 90% accept threshold, MGLRU with min_ttl_ms=1200ms, le9uo patches w/ default settings. The first two are in-tree and already suitable to make the machine deal nicely with memory pressure. le9uo (external patch) is the icing on the cake. I can compile qtwebengine/google chrome, which nearly uses all of my RAM and SWAP (32G/32G) and still have a responsive machine.

You can increase RAM usage efficiency with UKSM patch in conjunction with uksmd.

I still miss MuQSS.

I don't, its frametimes sucked.

[uid313]

That sounds like out of ram rather than CPU. MGLRU should have made that much better for you. Look into your swap settings and make sure your kernel has activated MGLRU.

Yes, it has happened when I ran out of RAM, but it also have happen when I did not run out of RAM (it happened after installing a package when apt ran the post-install trigger for gnome-menus).

I use the Ubuntu kernel so I don't know whether it has MGLRU activated or not. I do not have a swap. Running swapon --show outputs nothing.