The unified control group hierarchy in Linux kernel 3.16 | Hacker News Reader

The unified control group hierarchy in Linux kernel 3.16

lwn.net

70 pointschiachun8 comments

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/

* 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.

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

Also: https://www.kernel.org/doc/Documentation/cgroups/cgroups.txt

This is probably the best resource for namespaces if you are also interested in those: http://lwn.net/Articles/531114/

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.

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.

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

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

Hearing about cgroups always reminds me of the resource metering/dispensing parts of the KeyKOS papers. http://www.cis.upenn.edu/~KeyKOS/

Convergent evolution is fun. :)

Reply on news.ycombinator.com