sched.7: Further clarify details of group scheduling

After comments by Mike Galbraith.

Reported-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

diff --git a/man7/sched.7 b/man7/sched.7
index 99ad8065ff1c70e8c01c4bc73000c6d6369735a0..d82813158c2daa1355c4117510c23aa7dd93d6b7 100644 (file)
--- 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.
 
 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" .
 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.
 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
 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
 jobs on the system.
 
 A process's autogroup (task group) membership can be viewed via the file