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. to a task group.
This is done by writing a number in the "nice" range to the file This is done by writing a number in the "nice" range to the file
to set the task group's nice value. 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). The allowed range is from +19 (low priority) to \-20 (high priority).
Note that .\" FIXME
.I all .\" Because of a bug introduced in Linux 4.7
values in this range cause a task group to be further disfavored .\" (commit 2159197d66770ec01f75c93fb11dc66df81fd45b made changes
by the scheduler, .\" that exposed the fact that autogroup didn't call scale_load()),
with \-20 resulting in the scheduler mildy disfavoring .\" it happened that *all* values in this range caused a task group
the task group and +19 greatly disfavoring it. .\" to be further disfavored by the scheduler, with \-20 resulting
.\" FIXME Regarding the previous paragraph... .\" in the scheduler mildy disfavoring the task group and +19 greatly
.\" My tests indicate that writing *any* value to .\" disfavoring it.
.\" 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.
.\" .\"
.\" Is this the expected behavior? I presume it is... .\" A patch was posted on 23 Nov 2016
.\" .\" ("sched/autogroup: Fix 64bit kernel nice adjustment";
.\" But then there's a small surprise in the interface. Suppose that .\" check later to see in which kernel version it lands.
.\" 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?
.\" FIXME Is the following correct? Does the statement need to .\" FIXME Is the following correct? Does the statement need to
.\" be more precise? (E.g., in precisely which circumstances does .\" be more precise? (E.g., in precisely which circumstances does