The benefits of this for interactive desktop performance
can be described via the following example.
-Suppose that there are two autogroups competing for the same CPU.
+Suppose that there are two autogroups competing for the same CPU
+(i.e., presume either a single CPU system or the use of
+.BR taskset (1)
+to confine all the processes to the same CPU on an SMP system).
The first group contains ten CPU-bound processes from
a kernel build started with
.IR "make\ \-j10" .
That is, the video player will receive 50% of the CPU cycles,
rather than just 9% of the cycles,
which would likely lead to degraded video playback.
-Or to put things another way:
+The situation on an SMP system is more complex,
+.\" Mike Galbraith, 25 Nov 2016:
+.\" I'd say something more wishy-washy here, like cycles are
+.\" distributed fairly across groups and leave it at that, as your
+.\" detailed example is incorrect due to SMP fairness (which I don't
+.\" like much because [very unlikely] worst case scenario
+.\" renders a box sized group incapable of utilizing more that
+.\" a single CPU total). For example, if a group of NR_CPUS
+.\" size competes with a singleton, load balancing will try to give
+.\" the singleton a full CPU of its very own. If groups intersect for
+.\" whatever reason on say my quad lappy, distribution is 80/20 in
+.\" favor of the singleton.
+but the general effect is the same:
+the scheduler distributes CPU cycles across task groups such that
an autogroup that contains a large number of CPU-bound processes
-does not end up overwhelming the CPU at the expense of the other
+does not end up hoffing CPU cycles at the expense of the other
jobs on the system.
A process's autogroup (task group) membership can be viewed via the file