The Linux scheduler keeps evolving: How does the kernel schedule processes vs threads today? Do I need autogroups?
The previous similiar stack overflow question is many years old and likely obsolete.
I believe in 2018 the default is the Completely Fair Scheduler (CFS) instead of O(1) or other scheduler.
For Linux, some documentation mentions the OS juggles tasks which indifferently represent a process or a thread of a process, or does not clearly make the distinction though it's critical for scheduling.
For sake of clarity, a Process runs a program, and may spawn 1 or more threads when it is multi-threaded. For me the distinction is all threads of a process use the same virtual address space. However for scheduling on a CPU that distinction is irrelevant.
If I run P processes each with different Tp thread counts:
- Process fairness: How can I guarantee a process with many threads won't use up all resources and overpower a process with only 1 thread? Formalized, fair scheduling would mean: process P should get 1/Pth of the CPU resource, and have that 1/Pth split evenly to 1/(Pth*Tp) per thread of P. Is it what CFS guarantees by default?
- Do I need autogroups? Autogroups allow a process to schedule groups of tasks together. By default there's one group, but if you spin a 2nd one it will get 1/2 the CPU, spin 10 and each group of threads gets 1/10th. Simple (see gang scheduling).
- multi-core: I do not care too much to muddy the answer with considerations on load balancing for multi-cores and process migration between cores.
Experimental result: CFS seems to be fair between processes.
I tried on 4.9.27 to monitor the runtime of a small process vs a long running process with many threads. It seems that the scheduler on my kernel schedules by process, not by threads. So the small process was treated fairly and got 50% of the CPU. When I used 2 long running processes I got 33%. The slowdowns were like 2.2x and 3.4x respectively.
This kernel doesn't seem to have autogroups compiled in; setsid() works but seems to do nothing, AND /proc/*/autogroup doesn't exist, so trying to use autogroup while CFS seems to do the right thing is an expensive undertaking. However some other data points seem to indicate sometimes the behavior is not fair to a process.
Is there a trick to guarantee one process will run more regularly than all others? I can't promote it to realtime because of LD_LIBRARY_PATH usage I believe. And even then, I suspect because it reads /proc to monitor the system, it sometimes still got delayed massively when the system is heavily over capacity.