mirror of https://github.com/mkerrisk/man-pages
cgroups.7: Rework intro text a little
Signed-off-by: Michael Kerrisk <mtk.manpages@gmail.com>
This commit is contained in:
parent
28bcfee96d
commit
8bff71400e
|
@ -28,48 +28,14 @@
|
|||
cgroups \- Linux control groups
|
||||
.SH DESCRIPTION
|
||||
Control cgroups, usually referred to as cgroups,
|
||||
are a Linux kernel feature which provides for grouping of processes and
|
||||
resource tracking and limitations for those groups.
|
||||
While several systems have been introduced to help in configuring and
|
||||
managing cgroups, the kernel's cgroup interface is provided through
|
||||
are a Linux kernel feature which which allow processes to
|
||||
be organized into hierarchical groups whose usage of
|
||||
various types of resources can then be limited and monitored.
|
||||
The kernel's cgroup interface is provided through
|
||||
a pseudo-filesystem called cgroupfs.
|
||||
Grouping is implemented in the core cgroup kernel code,
|
||||
while resource tracking and limits are implemented in
|
||||
a set of per-resource-type subsystems (memory, CPU, and so on) which may be
|
||||
enabled as separate hierarchies, or joined into comounted hierarchies.
|
||||
|
||||
Each hierarchy constitutes a separate mount of the cgroup filesystem,
|
||||
with the subsystems enabled in that hierarchy listed in the mount options.
|
||||
For each mounted hierarchy,
|
||||
the directory tree mirrors the control group hierarchy.
|
||||
Each control group is represented by a directory, with each of its child
|
||||
control cgroups represented as a child directory.
|
||||
For instance,
|
||||
.IR /user/joe/1.session
|
||||
represents control group
|
||||
.IR 1.session ,
|
||||
which is a child of cgroup
|
||||
.IR joe ,
|
||||
which is a child of
|
||||
.IR /user .
|
||||
Under each cgroup directory is a set of files which can be read or
|
||||
written to, reflecting resource limits and a few general cgroup
|
||||
properties.
|
||||
|
||||
In general, cgroup limits are hierarchical, meaning that the limits placed on
|
||||
.IR /user/joe
|
||||
cannot be exceeded by
|
||||
.IR /usr/joe/1.session .
|
||||
There are currently exceptions to this rule,
|
||||
but stricter adherence is a goal as cgroups are being largely reworked.
|
||||
|
||||
In addition, cgroups can be mounted with no bound subsystem, in which case
|
||||
they serve only to track processes.
|
||||
An example of this is the
|
||||
.I name=systemd
|
||||
cgroup which is used by
|
||||
.BR systemd (1)
|
||||
to track services and user sessions.
|
||||
a set of per-resource-type subsystems (memory, CPU, and so on).
|
||||
.\"
|
||||
.SS Terminology
|
||||
A
|
||||
|
@ -96,6 +62,11 @@ renaming subdirectories within the cgroup filesystem.
|
|||
At each level of the hierarchy, attributes (e.g., limits) can be defined;
|
||||
these attributes may govern or propagate
|
||||
to child cgroups and their descendants in the hierarchy.
|
||||
|
||||
The limits, control, and accounting provided by cgroups are hierarchical.
|
||||
Thus, for example, the limits placed on
|
||||
a cgroup at a higher level in the hierarchy cannot be exceeded
|
||||
by descendant cgroups.
|
||||
.\"
|
||||
.SS Cgroups version 1 and version 2
|
||||
The initial release of the cgroups implementation was in Linux 2.6.24.
|
||||
|
@ -130,6 +101,39 @@ that are supported under version 2,
|
|||
while also using version 1 controllers
|
||||
where version 2 does not yet support those controllers.
|
||||
.\"
|
||||
.SS Cgroups version 1
|
||||
Under cgroups v1, each controller may be mounted against a separate
|
||||
cgroup filesystem that provides its own hierarchical organization of the
|
||||
processes on the system.
|
||||
It is also possible comount multiple (or even all) cgroups v1 controllers
|
||||
against the same cgroup filesystem, meaning that the comounted controllers
|
||||
manage the same hierarchical organization of processes.
|
||||
|
||||
For each mounted hierarchy,
|
||||
the directory tree mirrors the control group hierarchy.
|
||||
Each control group is represented by a directory, with each of its child
|
||||
control cgroups represented as a child directory.
|
||||
For instance,
|
||||
.IR /user/joe/1.session
|
||||
represents control group
|
||||
.IR 1.session ,
|
||||
which is a child of cgroup
|
||||
.IR joe ,
|
||||
which is a child of
|
||||
.IR /user .
|
||||
Under each cgroup directory is a set of files which can be read or
|
||||
written to, reflecting resource limits and a few general cgroup
|
||||
properties.
|
||||
|
||||
In addition, in cgroups v1,
|
||||
cgroups can be mounted with no bound subsystem, in which case
|
||||
they serve only to track processes.
|
||||
An example of this is the
|
||||
.I name=systemd
|
||||
cgroup which is used by
|
||||
.BR systemd (1)
|
||||
to track services and user sessions.
|
||||
.\"
|
||||
.SS Tasks (threads) versus processes
|
||||
In cgroups v1, a distinction is drawn between
|
||||
.I processes
|
||||
|
|
Loading…
Reference in New Issue