146

Is there a way to keep Linux responsive when at ~100% CPU usage? (feddit.dk)

submitted 7 months ago* (last edited 7 months ago) by SorteKanin@feddit.dk to c/linux@programming.dev

115 comments fedilink hide all child comments

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

[-] BB_C@programming.dev 4 points 7 months ago

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 running linux-ck.

Although I do use craneleft backend now day to day, so compiles don't take too long anyway.

[-] BB_C@programming.dev 3 points 7 months ago

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. cgroups should give you supported and well-tested tunable kernel-level resource usage control.

[-] potajito@lemmy.dbzer0.com 3 points 7 months ago

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

[-] SorteKanin@feddit.dk 3 points 7 months ago

I am on Wayland actually

[-] potajito@lemmy.dbzer0.com 4 points 7 months ago

Then it's wayland fault haha! Nah, hopefully it gets better!

[-] Rentlar@lemmy.ca 3 points 7 months ago

Yeah I think the philosophy of Linux is to not assume what you are going to be use it for. Why should Linux know where your priorities are better than you?

Some people want to run their rustc, ffmpeg or whatever intensive program and don't mind getting a coffee while that happens, or it's running on a non-user facing server anyway, to ensure that the process happens as soon as technically possible. Mind you that your case is not an "average usecase" either, not everyone is a developer that does compilation tasks.

So you've got a point that the defaults could be improved for the desktop software developer user or somehow made more easily configurable. As suggested downthread, try the nice command, an optimized scheduler or kernel, or pick a distribution equipped with that kind of kernel by default. The beauty of Linux is that there are many ways to solve a problem, and with varying levels of effort you can get things to pretty much exactly where you want them, rather than some crowdpleasing default.

[-] BearOfaTime@lemm.ee 4 points 7 months ago

There's a setting in windows to change the priority management, most people never see it.

By default it's configured for user responsiveness, but you can set it for service responsiveness.

Though this is nothing like the process priority management in Linux, it's one setting, that frankly I've never seen it make any difference. At least with Linux you can configure all sorts of priority management, on the fly no less.

Even with a server, you'd still want the UI to have priority. God knows when you do have to remote in, it's because you gotta fix something, and odds are the server is gonna be misbehavin' already.

load more comments (1 replies)

load more comments (3 replies)

[-] chakli@lemmy.world 3 points 7 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.

[-] merthyr1831@lemmy.world 3 points 7 months ago

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

[-] SorteKanin@feddit.dk 2 points 7 months ago

Interesting, thanks for sharing

[-] prof@infosec.pub 3 points 7 months ago

Ha, that's funny. When I run some Visual Studio builds on Windows it completely freezes at times.

Never have that issue on EOS with KDE.

[-] Valmond@lemmy.world 2 points 7 months ago

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)

[-] TunaCowboy@lemmy.world 2 points 7 months ago

Just use -j, --jobs: https://doc.rust-lang.org/cargo/commands/cargo-build.html#miscellaneous-options

[-] SorteKanin@feddit.dk 3 points 7 months ago

I actually tried that but I had to reduce it all the way to 4 jobs, which slows compilation down a lot.

load more comments (1 replies)

[-] eberhardt@discuss.tchncs.de 2 points 7 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.

[-] pocopene@lemmy.world 2 points 7 months ago

Cpulimit?

[-] agilob@programming.dev 2 points 7 months ago* (last edited 7 months ago)

EDIT: Tried nice -n +19, still lags my other programs.

yea, this is wrong way of doing things. You should have better results with CPU-pinning. Increasing priority for YOUR threads that interact all the time with disk io, memory caches and display IO is the wrong end of the stick. You still need to display compilation progress, warnings, access IO.

There's no way of knowing why your system is so slow without profiling it first. Taking any advice from here or elsewhere without telling us first what your machine is doing is missing the point. You need to find out what the problem is and report it at the source.