sched.7: Rework discussion of autogroup nice value

Remove the text saying that setting the autogroup nice value
always lowers the group's priority. That was actually a
bug introduced in Linux 4.7.

Also make it clearer that the autogroup nice value has the same
meaning as the nice value set by setpriority(2).

Reported-by: Mike Galbraith <efault@gmx.de>
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
Michael Kerrisk 2016-11-23 15:31:07 +01:00
parent 39b35179bc
commit 576b74eec2
1 changed files with 13 additions and 22 deletions

View File

@ -732,30 +732,21 @@ This file can also be used to modify the CPU bandwidth allocated
to a task group.
This is done by writing a number in the "nice" range to the file
to set the task group's nice value.
(For a discussion of the nice value, see
.BR getpriority (2).)
The allowed range is from +19 (low priority) to \-20 (high priority).
Note that
.I all
values in this range cause a task group to be further disfavored
by the scheduler,
with \-20 resulting in the scheduler mildy disfavoring
the task group and +19 greatly disfavoring it.
.\" FIXME Regarding the previous paragraph...
.\" My tests indicate that writing *any* value to
.\" the autogroup file causes the task group to get a lower
.\" priority. This somewhat surprised me, since I assumed
.\" (based on the parallel with the process nice(2) value)
.\" that negative values might boost the task group's priority
.\" above a task group whose autogroup file had not been touched.
.\" FIXME
.\" Because of a bug introduced in Linux 4.7
.\" (commit 2159197d66770ec01f75c93fb11dc66df81fd45b made changes
.\" that exposed the fact that autogroup didn't call scale_load()),
.\" it happened that *all* values in this range caused a task group
.\" to be further disfavored by the scheduler, with \-20 resulting
.\" in the scheduler mildy disfavoring the task group and +19 greatly
.\" disfavoring it.
.\"
.\" Is this the expected behavior? I presume it is...
.\"
.\" But then there's a small surprise in the interface. Suppose that
.\" the value 0 is written to the autogroup file, then this results
.\" in the task group being significantly disfavored. But,
.\" the nice value *shown* in the autogroup file will be the
.\" same as if the file had not been modified. So, the user
.\" has no way of discovering the difference. That seems odd.
.\" Am I missing something?
.\" A patch was posted on 23 Nov 2016
.\" ("sched/autogroup: Fix 64bit kernel nice adjustment";
.\" check later to see in which kernel version it lands.
.\" FIXME Is the following correct? Does the statement need to
.\" be more precise? (E.g., in precisely which circumstances does