One big difference that I’ve noticed between Windows and Linux is that Windows does a much better job ensuring that the system stays responsive even under heavy load.
For instance, I often need to compile Rust code. Anyone who writes Rust knows that the Rust compiler is very good at using all your cores and all the CPU time it can get its hands on (which is good, you want it to compile as fast as possible after all). But that means that for a time while my Rust code is compiling, I will be maxing out all my CPU cores at 100% usage.
When this happens on Windows, I’ve never really noticed. I can use my web browser or my code editor just fine while the code compiles, so I’ve never really thought about it.
However, on Linux when all my cores reach 100%, I start to notice it. It seems like every window I have open starts to lag and I get stuttering as the programs struggle to get a little bit of CPU that’s left. My web browser starts lagging with whole seconds of no response and my editor behaves the same. Even my KDE Plasma desktop environment starts lagging.
I suppose Windows must be doing something clever to somehow prioritize user-facing GUI applications even in the face of extreme CPU starvation, while Linux doesn’t seem to do a similar thing (or doesn’t do it as well).
Is this an inherent problem of Linux at the moment or can I do something to improve this? I’m on Kubuntu 24.04 if it matters. Also, I don’t believe it is a memory or I/O problem as my memory is sitting at around 60% usage when it happens with 0% swap usage, while my CPU sits at basically 100% on all cores. I’ve also tried disabling swap and it doesn’t seem to make a difference.
EDIT: Tried nice -n +19, still lags my other programs.
EDIT 2: Tried installing the Liquorix kernel, which is supposedly better for this kinda thing. I dunno if it’s placebo but stuff feels a bit snappier now? My mouse feels more responsive. Again, dunno if it’s placebo. But anyways, I tried compiling again and it still lags my other stuff.
All the comments here are great. One other suggestion I didn’t see: use chrt to start the build process with the sched_batch policy. It’s lower than sched_other, which most processes will be in, so the compilation processes should be bumped off the CPU for virtually everyone else
Sounds like Kubuntu’s fault to me. If they provide the desktop environment, shouldn’t they be the ones making it play nice with the Linux scheduler? Linux is configurable enough to support real-time scheduling.
FWIW I run NixOS and I’ve never experienced lag while compiling Rust code.
“The kernel runs out of time to solve the NP-complete scheduling problem in time.”
More responsiveness requires more context-switching, which then subtracts from the available total CPU bandwidth. There is a point where the task scheduler and CPUs get so overloaded that a non-RT kernel can no longer guarantee timed events.
So, web browsing is basically poison for the task scheduler under high load. Unless you reserve some CPU bandwidth (with cgroups, etc.) beforehand for the foreground task.
Since SMT threads also aren’t real cores (about ~0.4 - 0.7 of an actual core), putting 16 tasks on a 16/8 machine is only going to slow down the execution of all other tasks on the shared cores. I usually leave one CPU thread for “housekeeping” if I need to do something else. If I don’t, some random task is going to be very pleased by not having to share a core. That “spare” CPU thread will be running literally everything else, so it may get saturated by the kernel tasks alone.
nice +5is more of a suggestion to “please run this task with a worse latency on a contended CPU.”.(I think I should benchmark make -j15 vs. make -j16 to see what the difference is)
That’s all fine, but as I said, Windows seems to handle this situation without a hitch. Why can Windows do it when Linux can’t?
Also, it sounds like you suggest there is a tradeoff between bandwidth and responsiveness. That sounds reasonable. But shouldn’t Linux then allow me to easily decide where I want that tradeoff to lie? Currently I only have workarounds. Why isn’t there some setting somewhere to say “Yes, please prioritise responsiveness even if it reduces bandwidth a little bit”. And that probably ought to be the default setting. I don’t think a responsive UI should be questioned - that should just be a given.
You’re right of course. I think the issue is that Linux doesn’t care about the UI. As far as it is concerned GUI is just another program. That’s the same reason you don’t have things like ctrl-alt-del on Linux.
This hasn’t been my experience when no swapping is involved (not a concern for me anymore with 32GiB physical RAM with 28GiB zram).
And I’ve been Rusting since v1.0, and Linuxing for even longer.
And my setup is boring (and stable), using Arch’s LTS kernel which is built with
CONFIG_HZ=300. Long gone are the days of runninglinux-ck.Although I do use craneleft backend now day to day, so compiles don’t take too long anyway.
P.S. Since it wasn’t mentioned already, look up
cgroups.Back when I had a humble laptop (pre-Rust), using nice and co. didn’t help much. Custom schedulers come with their own stability and worst-case-scenario baggage.
cgroupsshould give you supported and well-tested tunable kernel-level resource usage control.
If you compile on windows server the same problem happens. The server is basically gone. So there seems to be some special scheduler configuration in windows client os.
I wonder if Linux should also provide server and desktop variants like Windows does, with different scheduler settings and such. The use cases are quite different after all, it’s kinda weird they use the same settings.
it’s typically up to the distribution to configure things like that, and many Linux distributions do come in both server and desktop or workstation variants like Ubuntu desktop vs Ubuntu server, or RHEL server vs RHEL Workstation
I can’t say how well they tune these things as I haven’t ran them personally, but they do exist.
