Cgroup V2's cpu.idle setting versus process niceness

December 13, 2024

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.

Written on 13 December 2024.
« Improving my desktop's responsiveness with the cgroup V2 'cpu.idle' setting
ZFS on Linux and block IO limits show some limits of being out of the kernel »

Page tools: View Source.
Search:
Login: Password:

Last modified: Fri Dec 13 22:45:20 2024
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.