mirror of https://github.com/mkerrisk/man-pages
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:
parent
39b35179bc
commit
576b74eec2
35
man7/sched.7
35
man7/sched.7
|
@ -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
|
||||||
|
|
Loading…
Reference in New Issue