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.
nice +5 cargo buildnice is a program that sets priorities for the CPU scheduler. Default is 0. Goes from -19, which is max prio, to +19 which is min prio.
This way other programs will get CPU time before cargo/rustc.
So the better approach would be to spawn all desktop and base GUI things with
nice -18or something?No. This will wreak havoc. At most at -1 but I’d advise against that. Just spawn the lesser-prioritised programs with a positive value.
Could you elaborate?
Critical operating system tasks run at -19. If they don’t get priority it will create all kinds of problems. Audio often runs below 0 as well, at perhaps -2, so music doesn’t stutter under load. Stuff like that.
Ok, nice. Do you know what other undefined processes are spawned with?
Default is 0. Also, processes inherit the priority of their parent.
This is another reason why starting the desktop environment as a whole with a different prio won’t work: the compiler is started as a child of the editor or shell which is a child of the DE so it will also have the changed prio.
Damn… thanks thats complicated
It’s more of a workaround than a solution. I don’t want to have to do this for every intensive program I run. The desktop should just be responsive without any configuration.
Yes, this is a bad solution. No program should have that privilege, it needs to be an allowlist and not a blocklist.
I face similar issue when updating steam games although I think that’s related to disk read write
But either way, issues like these gonna need to be address before we finally hit the year of Linux desktop lol
Lots of bad answers here. Obviously the kernel should schedule the UI to be responsive even under high load. That’s doable; just prioritise running those over batch jobs. That’s a perfectly valid demand to have on your system.
This is one of the cases where Linux shows its history as a large shared unix system and its focus as a server OS; if the desktop is just a program like any other, who’s to say it should have more priority than Rust?
I’ve also run into this problem. I never found a solution for this, but I think one of those fancy new schedulers might work, or at least is worth a shot. I’d appreciate hearing about it if it does work for you!
Hopefully in a while there are separate desktop-oriented schedulers for the desktop distros (and ideally also better OOM handlers), but that seems to be a few years away maybe.
In the short term you may have some success in adjusting the priority of Rust with nice, an incomprehensibly named tool to adjust the priority of your processes. High numbers = low priority (the task is “nicer” to the system). You run it like this:
nice -n5 cargo build.Obviously the kernel should schedule the UI to be responsive even under high load.
Obviously… to you.
This is one of the cases where Linux shows its history as a large shared unix system and its focus as a server OS; if the desktop is just a program like any other,
Exactly.
Obviously… to you.
No. I’m sorry but if you are logged in with a desktop environment, obviously the UI of that desktop needs to stay responsive at all times, also under heavy load. If you don’t care about such a basic requirement, you could run the system without a desktop or you could tweak it yourself. But the default should be that a desktop is prioritized and input from users is responded to as quickly as possible.
This whole “Linux shouldn’t assume anything”-attitude is not helpful. It harms Linux’s potential as a replacement for Windows and macOS and also just harms its UX. Linux cannot ever truly replace Windows and macOS if it doesn’t start thinking about these basic UX guarantees, like a responsive desktop.
This is one of the cases where Linux shows its history as a large shared unix system and its focus as a server OS; if the desktop is just a program like any other,
Exactly.
You say that like it’s a good thing; it is not. The desktop is not a program like any other, it is much more important that the desktop keeps being responsive than most other programs in the general case. Of course, you should have the ability to customize that but for the default and the general case, desktop responsiveness needs to be prioritized.
I meant, obviously in the sense that Windows and macOS both apparently already do this and that it’s a desirable property to have, not that it’s technically easy.
Firefox on my raspberry pi grinds the thing to a halt, so I created a shortcut:
systemd-run --scope -p MemoryLimit=500M -p CPUQuota=50% firefox-esr
You say it doesn’t top out on memory, so you don’t need the -p MemoryLimit=500M parameter. Set your compiler CPUQuota to maybe 80%, or whatever you can work out with trial and error.
Actually, I’ve experienced the opposite. I find Windows lagging much more often than Linux when compiling something, especially since Linux switched to the EEVDF scheduler. The most important factor that influences lag on both systems seems to be the power profile though. If I set my power profile to save battery, the system lags from time to time but if I set it to performance it basically never happens (on GNOME you can change that in the quick menu, not sure about KDE). It might be that your Windows is simply tuned more towards performance by default at the cost of higher power consumption.
So I just tried using
nice -n +19and it still lags my browser and my UI. So that’s not even a good workaround.Found this b for your problem of limiting one specific program such as rust compiler: https://askubuntu.com/questions/1367612/how-can-i-limit-the-cpu-and-ram-usage-for-a-process
OP most likely wants the opposite for the compiler…
I don’t really want to limit the Rust compiler. If I leave my computer running while I take a break, I don’t want it to artificially throttle the compiler. I just want user input and responsiveness of open windows to take priority over the compiler.
Linux defaults are optimized for performance and not for desktop usability.
If that is the case, Linux will never be a viable desktop OS alternative.
Either that needs to change or distributions targeting desktop needs to do it. Maybe we need desktop and server variants of Linux. It kinda makes sense as these use cases are quite different.
EDIT: I’m curious about the down votes. Do people really believe that it benefits Linux to deprioritise user experience in this way? Do you really think Linux will become an actual commonplace OS if it keeps focusing on “performance” instead of UX?
“Desktop” Linux exists in this state for decades. Who cares? Maybe we won’t have consumer desktops as a niche soon. Existing users are fine with that. Don’t say you are waiting that Linux will become “a viable desktop OS alternative” in next few years.
It’s also not about “desktop and sever variants”. Desktop Linux is either conservative or underresourced. Conservatives will told you that you are wrong and there is no issue. And they are major Linux zealots. For the other side someone need to write code and do system design, and there are not many of people for that. So, it’s better not to expect a solution anytime soon, if you are not planning to work on it by yourself.
“Desktop” Linux exists in this state for decades. Who cares?
I mean, I’d like to think a lot of people care? I think a lot of people in this community would love if Linux was more widespread and less niche.
Maybe we won’t have consumer desktops as a niche soon. Existing users are fine with that.
“Existing users” are not fine with that (I am also an existing user). But even if they were, that is not an attitude that will make Linux into a Windows/macOS competitor.
Don’t say you are waiting that Linux will become “a viable desktop OS alternative” in next few years.
We need a viable desktop alternative today or very soon more now than ever before. Microsoft is tightening the noose on Windows 11 and introducing more and more enshittification. Apple also announced AI partnerships recently. We need alternatives.
It is not good for society for operating systems to be boiled down to two mega-corporate choices. An OS is not something that can be easily made - this is not a space that a competitor can quickly enter and shake things up. If we don’t push MS/Apple off the throne, Linux will stay niche forever and society will suffer.
Society will suffer anyway. It doesn’t make solutions magically appear. You only said why you want it, but not how to do it. To transform GNU/Linux distros into a viable desktop OS is not an easy task, especially when people don’t have a consensus about what it should be.
Of course - I have actually lately been thinking if Linux is suffering from it’s “decentralisation”. There are so many distributions, all with their own structure and teams behind them. On the one hand, this is great, more choice is almost universally good.
However, on the other hand, it leads to a much more fractured movement. Imagine instead of there being 100 or whatever distros, there were maybe just like… 5 or 10 or something. I feel like it’d be easier to rally under fewer flags to consolidate effort and avoid double work. But it’s just a thought I’ve had lately.
Distros are unnecessary entities and don’t improve anything here. What is needed it’s separation of the system and the apps, where apps are provided in sandboxed bundles with permissions. It will solve a lot of issues, not only one you have mentioned. And try to imagine amount of years needed for understanding or explaining importance of this to the GNU/Linux community. A viable desktop OS, huh?
Are you on x11 or wayland? For me x11 behaves really bad on these situations, and wayland is much much snappier.
I am on Wayland actually
Then it’s wayland fault haha! Nah, hopefully it gets better!
While I ultimately think your solution is to use a different scheduler, and that the most useful responses you’ve gotten have been about that; and that I agree with your response that Linux distros should really be tuning the scheduler for the UI by default and let developers and server runners take the burden of tuning differently for their workloads… all that said, I can’t let this comment on your post go by:
which is good, you want it to compile as fast as possible after all
If fast compile times are your priority, you’re using the wrong programming language. One of Go’s fundamental principles is fast compile times; even with add-on caching tooling in other languages, Go remains one of the fastest-compiling statically compiled, strongly typed programming languages available. I will not install Haskell programs unless they’re precompiled bin packages, that’s a hard rule. I will only reluctantly install Rust packages, and will always choose bins if available. But I’ll pick a
-gitGo package without hesitation, because they build crazy fast.Anyway, I hope you find the scheduler of your dreams and live happily ever after.
I only said as fast as possible - I generally think the compile times are fine and not a huge problem. Certainly worth it for all the benefits.
I experience the exact same thing.
The key is that you need to allow processes in your oom killer. There are different implementations like
oomdorearlyoom.Oomd freezes and doesnt kill, and I suppose distros do a bad job at allowlisting the desktop etc in there.
As I mention at the end, this situation has nothing to do with running out of memory. It’s purely CPU starvation.
Thanks, yes this can have 2 causes and both need to be fixed.
deleted by creator
You didn’t read my whole post it seems.
yeah i missed the part about the zero swap usage
