Cgroup V2's cpu.idle setting versus process niceness
In a comment on my entry on improving my desktop's responsiveness with the cgroup V2 'cpu.idle' setting, Leah Neukirchen asked a good question:
How does this differ in practice to just using a high niceness for these jobs?
This is a good question and after doing some quick experiments, at the moment I have only partial answers. Let's start out with the basics. If you want to leave interactive programs happy with life on your Linux desktop with a reasonably decent core count while you do something CPU intensive, such as build Firefox, you have (at least) three options.
First, you can nice(1) everything down
to the lowest regular priority, with 'nice -n 19 ...
'. Second,
you can arrange to run everything at SCHED_IDLE priority, either
through the cgroup V2 cpu.idle setting
or with 'chrt -i 0 ...'. Finally, you can restrict which CPUs
the build process runs on
using taskset(1),
so that your desktop and other programs have plenty of idle CPUs
to run on.
(If you use taskset here with a significant number of cores, and your system has SMT/HT, you'll want to make sure that you don't use all of one side of the SMT pairs, because that won't really leave you with idle cores for your regular processes. This is tricky because SMT pairs aren't always numbered one after the other.)
On my current desktop setups, where I now have enough memory to do these builds without significant memory pressure, nice(1) appears to leave my desktop basically as responsive as the cpu.idle approach, although it's possible that there's a bit more lag in some operations. My memory of past experience, on my desktop with less memory, is that nice(1) was not enough to make a brand name video conferencing tool happy, but that the CPU fencing approach with taskset(1) did keep it from complaining (I haven't yet tried with the cpu.idle approach).
My expectation is that SCHED_IDLE is more certain to keep your big build out of the way of your desktop because even heavily nice'd processes are supposed to get some CPU time even if your CPU is fully in demand, just not very much of it. By contrast, it's explicit and part of the design that SCHED_IDLE processes won't run if any normal process wants to run. I don't know if the two options behave differently when there's a running nice'd or 'idle' process and a regular process waks up and wants to run, but I think it's possible that the Linux scheduler is more aggressive about throwing a SCHED_IDLE process off the CPU than it is for a nice'd process.
|
|