address (it is sent a `SIGSEGV` signal, typically killing it with the famous
  `Segmentation fault` message). The latter can happen when the process reads
  from a memory zone which has been swapped out, or which corresponds to a mapped
  file: in that case, the kernel loads the page from disk, and let the CPU
  complete the memory access. It can also happen when the process writes to a
  copy-on-write memory zone: likewise, the kernel preempts the process, duplicate
  the memory page, and resume the write operation on the process's own copy of
  the page. "Major" faults happen when the kernel actually needs to read the data
  from disk. When it just duplicates an existing page, or allocate an empty page,
  it's a regular (or "minor") fault.

`swap`
: The amount of swap currently used by the processes in this cgroup.

`active_anon`, `inactive_anon`
: The amount of anonymous memory that has been identified has respectively
  _active_ and _inactive_ by the kernel. "Anonymous" memory is the memory that is
  _not_ linked to disk pages. In other words, that's the equivalent of the rss
  counter described above. In fact, the very definition of the rss counter is
  `active_anon` + `inactive_anon` - `tmpfs` (where tmpfs is the amount of
  memory used up by `tmpfs` filesystems mounted by this control group). Now,
  what's the difference between "active" and "inactive"? Pages are initially
  "active"; and at regular intervals, the kernel sweeps over the memory, and tags
  some pages as "inactive". Whenever they're accessed again, they're
  immediately re-tagged "active". When the kernel is almost out of memory, and
  time comes to swap out to disk, the kernel swaps "inactive" pages.

`active_file`, `inactive_file`
: Cache memory, with _active_ and _inactive_ similar to the _anon_ memory
  above. The exact formula is `cache` = `active_file` + `inactive_file` +
  `tmpfs`. The exact rules used by the kernel to move memory pages between
  active and inactive sets are different from the ones used for anonymous memory,
  but the general principle is the same. When the kernel needs to reclaim memory,
  it's cheaper to reclaim a clean (=non modified) page from this pool, since it
  can be reclaimed immediately (while anonymous pages and dirty/modified pages
  need to be written to disk first).

`unevictable`
: The amount of memory that cannot be reclaimed; generally, it accounts for
  memory that has been "locked" with `mlock`. It's often used by crypto
  frameworks to make sure that secret keys and other sensitive material never
  gets swapped out to disk.

`memory_limit`, `memsw_limit`
: These aren't really metrics, but a reminder of the limits applied to this
  cgroup. The first one indicates the maximum amount of physical memory that can
  be used by the processes of this control group; the second one indicates the
  maximum amount of RAM+swap.

Accounting for memory in the page cache is very complex. If two
processes in different control groups both read the same file
(ultimately relying on the same blocks on disk), the corresponding
memory charge is split between the control groups. It's nice, but
it also means that when a cgroup is terminated, it could increase the
memory usage of another cgroup, because they're not splitting the cost
anymore for those memory pages.

### CPU metrics: `cpuacct.stat`

Now that we've covered memory metrics, everything else is
simple in comparison. CPU metrics are in the
`cpuacct` controller.

For each container, a pseudo-file `cpuacct.stat` contains the CPU usage
accumulated by the processes of the container, broken down into `user` and
`system` time. The distinction is:

- `user` time is the amount of time a process has direct control of the CPU,
  executing process code.
- `system` time is the time the kernel is executing system calls on behalf of
  the process.

Those times are expressed in ticks of 1/100th of a second, also called "user
jiffies". There are `USER_HZ` _"jiffies"_ per second, and on x86 systems,