

The unified control group hierarchy in Linux kernel 3.16 - chiachun
http://lwn.net/Articles/601840/

======
gioele
In the last weeks, the kernel developer Neil Brown has been contributing a
series of very in-depth articles about cgroups and hierarchies in the current
kernel in general. Worth reading and worth paying LWN to access the content
(and the associated discussions) as soon as it is published.

[https://lwn.net/Articles/604609/](https://lwn.net/Articles/604609/)

* Control groups, part 1: On the history of process grouping — a look at the history of grouping processes, going back to the early days of Unix.

* Control groups, part 2: On the different sorts of hierarchies — a look at hierarchies, including some from inside Linux and some from outside.

* Control groups, part 3: First steps to control — a look at the more simple cgroup subsystems.

* Control groups, part 4: On accounting — hierarchical accounting in the remaining cgroup subsystems.

* Control groups, part 5: The cgroup hierarchy — options and implications for hierarchical structure.

------
maggit
I had no idea what a control group is, so here is a short summary for others
in my position:

\- cgroups (abbreviated from control groups) is a Linux kernel feature to
limit, account, and isolate resource usage (CPU, memory, disk I/O, etc.) of
process groups.

\- Various projects are using cgroups as their basis, including Docker

[http://en.wikipedia.org/wiki/Cgroups](http://en.wikipedia.org/wiki/Cgroups)

~~~
jpgvm
Technically isolation is actually implemented in what we call Linux namespaces
(which are analogous to Solaris Zones/BSD jails etc) and are not part of the
cgroups infrastructure per se.

The definition above comes from wikipedia and is incorrect in my opinion.

Cgroups only really encompasses accounting, limits and some other cool
functionality (like freezer, which allows you to atomically pause groups of
processes).

Namespaces on the other hand implement namespacing of all the crucial
resources like UIDs, PIDs, devices (including network adapters), routing
tables etc and form the basis of the "security" part of a container.

It just so happens that people tend to think of them as one thing as their
only interaction with them so far has been LXC/Docker/Heroku/Borg when in
reality they are much richer systems that can be used to do all sorts of cool
things.

~~~
menage
Being able to ensure that your important job gets a certain fraction of the
CPU, memory or I/O resources regardless of what other jobs on the same machine
are doing is very much an instance of 'resource isolation' \- in terms of
usage, rather than access/naming which is the kind of isolation that
namespaces provide.

CGroups can theoretically provide resource access isolation too, e.g. the
device security cgroup subsystem, but it's not really the ideal model for it.

FWIW, Borg (at least as of a few years ago - it's possible that it's changed
now) hardly uses any resource access isolation - apart from a bit of bind-
mount trickery to provide filesystem isolation, it's primarily concerned with
resource usage isolation, and jobs are very aware that they're running on the
same kernel with potentially many other jobs.

------
jpgvm
Huge props to Tejun Heo and everyone else involved in this effort.

This is a big deal in our modern container powered ecosystem.

------
tbrownaw
Hearing about cgroups always reminds me of the resource metering/dispensing
parts of the KeyKOS papers.
[http://www.cis.upenn.edu/~KeyKOS/](http://www.cis.upenn.edu/~KeyKOS/)

Convergent evolution is fun. :)

