diff --git a/man7/sched.7 b/man7/sched.7
index 99ad8065f..d82813158 100644
--- a/man7/sched.7
+++ b/man7/sched.7
@@ -717,7 +717,10 @@ distribution of CPU cycles across task groups.
 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" .
@@ -727,9 +730,22 @@ each receive half of the CPU cycles.
 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