On Tue, 2016-11-22 at 16:59 +0100, Michael Kerrisk (man-pages) wrote: > ┌─────────────────────────────────────────────────────┐ > │FIXME │ > ├─────────────────────────────────────────────────────┤ > │The following is a little vague. Does it need to be │ > │made more precise? │ > └─────────────────────────────────────────────────────┘ > The CFS scheduler employs an algorithm that distributes the CPU > across task groups. As a result of this algorithm, the pro‐ > cesses in task groups that contain multiple CPU-intensive pro‐ > cesses are in effect disfavored by the scheduler. Mmmm, they're actually equalized (modulo smp fairness goop), but I see what you mean. > A process's autogroup (task group) membership can be viewed via > the file /proc/[pid]/autogroup: > > $ cat /proc/1/autogroup > /autogroup-1 nice 0 > > This file can also be used to modify the CPU bandwidth allo‐ > cated 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. > The allowed range is from +19 (low priority) to -20 (high pri‐ > ority). Note that 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. Group nice levels exactly work the same as task nice levels, ie negative nice increases share, positive nice decreases it relative to the default nice 0. > ┌─────────────────────────────────────────────────────┐ > │FIXME │ > ├─────────────────────────────────────────────────────┤ > │Regarding the previous paragraph... My tests indi‐ │ > │cate that writing *any* value to the autogroup file │ > │causes the task group to get a lower priority. (patchlet.. I'd prefer to whack the knob, but like the on/off switch, it may be in use, so I guess we're stuck with it) > ┌─────────────────────────────────────────────────────┐ > │FIXME │ > ├─────────────────────────────────────────────────────┤ > │Is the following correct? Does the statement need to │ > │be more precise? (E.g., in precisely which circum‐ │ > │stances does the use of cgroups override autogroup?) │ > └─────────────────────────────────────────────────────┘ > The use of the cgroups(7) CPU controller overrides the effect > of autogrouping. Correct, autogroup defers to cgroups. Perhaps mention that moving a task back to the root task group will result in the autogroup again taking effect. > ┌─────────────────────────────────────────────────────┐ > │FIXME │ > ├─────────────────────────────────────────────────────┤ > │What needs to be said about autogroup and real-time │ > │tasks? │ > └─────────────────────────────────────────────────────┘ That it does not group realtime tasks, they are auto-deflected to the root task group. -Mike -- To unsubscribe from this list: send the line "unsubscribe linux-man" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
