Correct behaviour under a CPUQuota= setting

Posted Feb 12, 2025 19:53 UTC (Wed) by farnz (subscriber, #17727)
In reply to: using coreutils in production by intelfx
Parent article: Rewriting essential Linux packages in Rust

It depends on whether you've got bursty work, or saturate your threads.

If your workload is bursty - a lot of work for a small fraction of the period used by CPUQuota, then idle for the rest of the period - you might want a thread per core so that when work comes in, you spread across all cores, get it done, and go back to idle. If your workload saturates all possible threads - so it'll be throttled by CPUQuota - you usually want just enough threads to allow you to saturate your quota, and no more (e.g. 3 threads for a quota of 250%); doing so means that you benefit from the cache effects of holding onto a single CPU core for longer, rather than being throttled most of the time and hitting a cooler cache when you can run.

And if you're I/O bound, chances are good that you can't make good use of a large number of threads anyway, because you're spending all your time stuck waiting for I/O on one thread or on 128 threads. You might as well, in this situation, just use 2 threads and save the complexity of synchronising many threads.

I thus believe it's rare to want thread per CPU core when you have a CPUQuota control group limit.