cgroups.7: Relocate the 'Cgroups v2 "no internal processes" rule' subsection

Logically, this section should follow the section that
describes cgroup.subtree_control.

No content changes in this patch.

Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>

man7/cgroups.7

@@ -619,51 +619,6 @@ and
 .I cpuacct
 controllers.
 .\"
-.SS Cgroups v2 """no internal processes""" rule
-Cgroups v2 enforces a so-called "no internal processes" rule.
-Roughly speaking, this rule means that,
-with the exception of the root cgroup, processes may reside
-only in leaf nodes (cgroups that do not themselves contain child cgroups).
-This avoids the need to decide how to partition resources between
-processes which are members of cgroup A and processes in child cgroups of A.
-.PP
-For instance, if cgroup
-.I /cg1/cg2
-exists, then a process may reside in
-.IR /cg1/cg2 ,
-but not in
-.IR /cg1 .
-This is to avoid an ambiguity in cgroups v1
-with respect to the delegation of resources between processes in
-.I /cg1
-and its child cgroups.
-The recommended approach in cgroups v2 is to create a subdirectory called
-.I leaf
-for any nonleaf cgroup which should contain processes, but no child cgroups.
-Thus, processes which previously would have gone into
-.I /cg1
-would now go into
-.IR /cg1/leaf .
-This has the advantage of making explicit
-the relationship between processes in
-.I /cg1/leaf
-and
-.IR /cg1 's
-other children.
-.PP
-The "no internal processes" rule is in fact more subtle than stated above.
-More precisely, the rule is that a (nonroot) cgroup can't both
-(1) have member processes, and
-(2) distribute resources into child cgroups\(emthat is, have a nonempty
-.I cgroup.subtree_control
-file.
-Thus, it
-.I is
-possible for a cgroup to have both member processes and child cgroups,
-but before controllers can be enabled for that cgroup,
-the member processes must be moved out of the cgroup
-(e.g., perhaps into the child cgroups).
-.\"
 .SS Cgroups v2 subtree control
 Each cgroup in the v2 hierarchy contains the following two files:
 .TP
@@ -725,6 +680,51 @@ then the corresponding controller-interface files (e.g.,
 are automatically created in the children of that cgroup
 and can be used to exert resource control in the child cgroups.
 .\"
+.SS Cgroups v2 """no internal processes""" rule
+Cgroups v2 enforces a so-called "no internal processes" rule.
+Roughly speaking, this rule means that,
+with the exception of the root cgroup, processes may reside
+only in leaf nodes (cgroups that do not themselves contain child cgroups).
+This avoids the need to decide how to partition resources between
+processes which are members of cgroup A and processes in child cgroups of A.
+.PP
+For instance, if cgroup
+.I /cg1/cg2
+exists, then a process may reside in
+.IR /cg1/cg2 ,
+but not in
+.IR /cg1 .
+This is to avoid an ambiguity in cgroups v1
+with respect to the delegation of resources between processes in
+.I /cg1
+and its child cgroups.
+The recommended approach in cgroups v2 is to create a subdirectory called
+.I leaf
+for any nonleaf cgroup which should contain processes, but no child cgroups.
+Thus, processes which previously would have gone into
+.I /cg1
+would now go into
+.IR /cg1/leaf .
+This has the advantage of making explicit
+the relationship between processes in
+.I /cg1/leaf
+and
+.IR /cg1 's
+other children.
+.PP
+The "no internal processes" rule is in fact more subtle than stated above.
+More precisely, the rule is that a (nonroot) cgroup can't both
+(1) have member processes, and
+(2) distribute resources into child cgroups\(emthat is, have a nonempty
+.I cgroup.subtree_control
+file.
+Thus, it
+.I is
+possible for a cgroup to have both member processes and child cgroups,
+but before controllers can be enabled for that cgroup,
+the member processes must be moved out of the cgroup
+(e.g., perhaps into the child cgroups).
+.\"
 .SS Cgroups v2 cgroup.events file
 With cgroups v2, a new mechanism is provided to obtain notification
 about when a cgroup becomes empty.