this post was submitted on 18 Jun 2024
140 points (96.1% liked)

Linux

5191 readers
170 users here now

A community for everything relating to the linux operating system

Also check out [email protected]

Original icon base courtesy of [email protected] and The GIMP

founded 1 year ago
MODERATORS
 

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.

(page 2) 50 comments
sorted by: hot top controversial new old
[–] [email protected] 4 points 4 months ago

Yep, CPU scheduler is the correct answer. Id recommend reading this arch wiki on it. https://wiki.archlinux.org/title/improving_performance

[–] [email protected] 4 points 4 months ago (8 children)

Linux defaults are optimized for performance and not for desktop usability.

load more comments (8 replies)
[–] [email protected] 4 points 4 months ago* (last edited 4 months ago) (5 children)

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 -git Go package without hesitation, because they build crazy fast.

Anyway, I hope you find the scheduler of your dreams and live happily ever after.

load more comments (5 replies)
[–] [email protected] 3 points 4 months ago

I always did make -j$(nproc --ignore=1) to avoid this while building cpp code. But this problem seems to be less severe if there are a lot of cores.

[–] [email protected] 3 points 4 months ago (1 children)

TLDR you might be interested in the rust-based scheduler one of the Canonical Devs released as a PoC. Seemed to be designed similar to your needs of keeping the system (particularly games) responsive even whilst running heavy tasks like kernel compilations. You can swap out schedulers at run time on Linux iirc?

https://www.phoronix.com/news/Rust-Linux-Scheduler-Experiment

[–] [email protected] 2 points 4 months ago

Interesting, thanks for sharing

[–] [email protected] 2 points 4 months ago

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.

[–] [email protected] 2 points 4 months ago
[–] [email protected] 2 points 4 months ago (1 children)

Are you on x11 or wayland? For me x11 behaves really bad on these situations, and wayland is much much snappier.

[–] [email protected] 3 points 4 months ago (1 children)
load more comments (1 replies)
[–] [email protected] 2 points 4 months ago (2 children)

My work windoz machine clogged up quite much recompiling large projects (GB s of C/C++ code), so I set it to use 19/20 "cores". Worked okayish but was not some snappy experience IMO (64GB RAM & SSD).

load more comments (2 replies)
[–] [email protected] 1 points 4 months ago (2 children)

I experience the exact same thing.

The key is that you need to allow processes in your oom killer. There are different implementations like oomd or earlyoom.

Oomd freezes and doesnt kill, and I suppose distros do a bad job at allowlisting the desktop etc in there.

[–] [email protected] 1 points 4 months ago (1 children)

As I mention at the end, this situation has nothing to do with running out of memory. It's purely CPU starvation.

[–] [email protected] 1 points 4 months ago

Thanks, yes this can have 2 causes and both need to be fixed.

load more comments (1 replies)
[–] [email protected] 1 points 4 months ago

Hmm, I can't say that I've ever noticed this. I have a 3950x 16-core CPU and I often do video re-encoding with ffmpeg on all cores, and occasionally compile software on all cores too. I don't notice it in the GUI's responsiveness at all.

Are you absolutely sure it's not I/O related? A compile is usually doing a lot of random IO as well. What kind of drive are you running this on? Is it the same drive as your home directory is on?

Way back when I still had a much weaker 4-core CPU I had issues with window and mouse lagging when running certain heavy jobs as well, and it turned out that using ionice helped me a lot more than using nice.

I also remember that fairly recently there was a KDE/plasma stutter bug due to it reading from ~/.cache constantly. Brodie Robertson talked about it: https://www.youtube.com/watch?v=sCoioLCT5_o

load more comments
view more: ‹ prev next ›