On Tue, 2016-11-29 at 10:10 +0100, Michael Kerrisk (man-pages) wrote: > Let's try and go further. How's this: > > When scheduling non-real-time processes (i.e., those scheduled > under the SCHED_OTHER, SCHED_BATCH, and SCHED_IDLE policies), the > CFS scheduler employs a technique known as "group scheduling", if > the kernel was configured with the CONFIG_FAIR_GROUP_SCHED option > (which is typical). > > Under group scheduling, threads are scheduled in "task groups". > Task groups have a hierarchical relationship, rooted under the > initial task group on the system, known as the "root task group". > Task groups are formed in the following circumstances: > > * All of the threads in a CPU cgroup form a task group. The par‐ > ent of this task group is the task group of the corresponding > parent cgroup. > > * If autogrouping is enabled, then all of the threads that are > (implicitly) placed in an autogroup (i.e., the same session, as > created by setsid(2)) form a task group. Each new autogroup is > thus a separate task group. The root task group is the parent > of all such autogroups. > > * If autogrouping is enabled, then the root task group consists > of all processes in the root CPU cgroup that were not otherwise > implicitly placed into a new autogroup. > > * If autogrouping is disabled, then the root task group consists > of all processes in the root CPU cgroup. > > * If group scheduling was disabled (i.e., the kernel was config‐ > ured without CONFIG_FAIR_GROUP_SCHED), then all of the pro‐ > cesses on the system are notionally placed in a single task > group. Notionally works for me. -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
