图解｜cgroup 设计分析（Docker底层技术）

cgroup 可能很多人都不了解，但提起 Docker 估计每个后端程序员都了解过。是的，Docker 已经成为程序员必须掌握的技术之一了。Docker 主要解决了传统虚拟机启动慢、占用大量资源的缺点。

当然，本文的重点并不是 Docker，而是 Docker 的底层支撑技术 cgroup。可以这样说，没有 cgroup 就没有 Docker。

什么是 cgroup

cgroup 的全称为 control group，中文翻译为 控制组。主要用于控制进程组对某种资源的使用，这些资源包括但不限于：内存、CPU、I/O 和 网络 等。

如下图所示，使用 cgroup 来限制进程组对内存的使用：

（图1）

在上图中，我们创建了 2 个 cgroup（每个 cgroup 有 4 个进程），并且限制它们各自最多只能使用 2GB 的内存。如果使用超过 2GB 的内存，那么将会触发 OOM（Out Of Memory） 错误。

cgroup 通过把进程划分成控制组（一个控制组包含一个或多个进程），并且可以对控制组进行资源使用的控制，也就是说 cgroup 作用对象是控制组。

cgroup 提供了将进程组织成控制组的能力，然后通过使用 资源控制子系统（cgroup_subsys） 来对控制组进行资源使用的控制，cgroup 支持的 资源控制子系统 有以下几种：

• cpu子系统：限制 CPU 的使用。
• memory子系统：限制内存使用。
• cpuset子系统：可以为进程组分配单独的 CPU 或者内存节点。
• cpuacct子系统：统计CPU group的使用情况。
• blkio子系统：限制I/O，一般用于磁盘。
• devices子系统：限制进程使用的设备。
• freezer子系统：可以挂起和恢复进程组。
• net_cls子系统：可以标记进程组的网络数据包，使用 tc 模块（traffic control）对数据包进行控制。

也就是说，cgroup 通过把进程组织成 控制组，然后通过 资源控制子系统 来对 控制组 进行资源使用的限制，所以 cgroup 的分析可以分成两部分：cgroup框架 和 资源控制子系统。

cgroup 源码分析

cgroup 的设计还是比较复杂的，主要是因为 cgroup 涉及多种资源的控制，并且 cgroup 通过虚拟文件系统来组织进程控制组，所以导致 cgroup 的实现变得复杂难懂。

cgroup 的概念和使用可以参考这篇文章：《cgroup介绍》。

为了不会让大家陷入枯燥的概念和源码之中，本文主要通过以设计者的角度来分析 cgroup 的设计与实现。

OK，Let's go！

1. 设计一个简单的 cgroup

如果让你来设计一个限制进程组对内存使用的方案，你会怎么设计呢？

最简单的方法就是，创建一个内存使用的计数器，然后将进程组中所有的进程都指向这个计数器。当进程组的进程申请内存时，就增加计数器的值，如果计数器超过限制就触发错误。如下图所示：

（图2）

上图中计数器的 limit 字段表示限制进程中使用的最大内存数，而 count 字段表示当前进程使用的内存数。每当进程组中的进程申请内存时，都需要增加计数器的 count 字段，并且比较 count 是否已经超出 limit 的限制。

数据结构可以这样设计：

（图3）

我们通过链表来将进程组织成进程组，并且在计数器中增加一个 task_group 字段，让其指向进程组。当进程组中的进程申请内存时，可以通过指针来找到对应的计数器，并且增加计数器的 count 字段。

就这样，我们设计了一个简单的 cgroup 功能。如果系统只有内存这种资源的话，的确可以这样设计。但是系统除了内存，还有CPU、硬盘和网络这些资源，所以 Linux 创建了一种比较通用的方式来组织进程组。

2. 控制组

有了上面的雏形，cgroup 的很多概念就比较容易理解了，下面主要介绍一下 控制组 这个概念。

控制组 说白了就是一组进程（进程组），cgroup 就是用来限制 控制组 的资源使用。为了能够方便地向一个 控制组 添加或者移除进程（在命令行也能操作），内核使用了 虚拟文件系统 来进行管理 控制组。

我们可以把一个 控制组 当成是一个目录，由于目录有层级关系，所以 控制组 也有层级关系，如下图所示：

（图4）

如上图所示，控制组 是以目录树来组织的，每一个目录代表一个 控制组。在内核中，一个由 控制组 组成的目录树被称为 层级（hierarchy）。

每个控制组目录中，都有一个名为 tasks 的文件，用于保存当前 控制组 包含的进程列表。如果我们想向某个 控制组 添加一个进程时，可以把进程的 PID 写入到 tasks 文件中。例如：

$ cd /sys/fs/cgroup/memory/cgrp1    # 进入控制组cgrp1
$ echo 1029 > tasks                 # 将PID为1029的进程添加到cgrp1控制组中

我们也可以通过读取 tasks 文件来查看某个 控制组 中的进程列表，例如：

$ cat tasks
1
2
3
5
6
7
...

在内核中，控制组使用 cgroup 结构来表示，其定义如下：

struct cgroup {
    ...
    // 下面3个字段把控制组连接成一个树结构
    struct list_head sibling;   // 兄弟节点
    struct list_head children;  // 子节点
    struct cgroup *parent;      // 父节点

    struct dentry *dentry;      // 当前控制组对应的目录对象

    // 当前控制组关联的子系统资源统计对象
    struct cgroup_subsys_state *subsys[CGROUP_SUBSYS_COUNT]; 
    ...
};

内核通过 cgroup 结构的 sibling、children 和 parent 这3个字段来将 控制组 组织成一棵树状结构。如下图所示：

（图5）

另外，cgroup 结构的 subsys 字段表示当前控制组关联的子系统状态对象，下面介绍 资源控制子系统 时将会详细介绍。

在 Linux 内核中，可以存在多个 层级（控制组树），每个层级可以关联一个或多个 资源控制子系统，但同一个 资源控制子系统 不能关联到多个层级中（也就是说，同一种 资源控制子系统 只能关联到一个层级）。如下图所示：

（图6）

在内核中，层级 的根结点使用 cgroupfs_root 结构来表示， 我们来看看其定义：

struct cgroupfs_root {
    struct super_block *sb;            // 挂载点超级块对象（虚拟文件系统使用）
    unsigned long subsys_bits;         // 当前层级绑定的资源子系统位图（1表示已经绑定到当前层级）
    ...
    struct list_head subsys_list;      // 绑定到当前层级的资源子系统列表
    struct cgroup top_cgroup;          // 当前层级的根控制组
    int number_of_cgroups;             // 当前层级拥有的控制组数量
    ...
};

在 Linux 内核中，有个名为 rootnode 的根层级，在系统启动后，由内核自动创建并且初始化的层级。系统启动后，所有的资源控制子系统都关联到此层级。rootnode 的定义如下：

// 定义在文件 ./kernel/cgroup.c 中

static struct cgroupfs_root rootnode;

如果用户想把资源控制子系统关联到其他层级，那么可以使用 mount 命令来进行挂载，如下命令所示：

$ mount -t cgroup -o memory memory /sys/fs/cgroup/memory

上面的命令用于将内存子系统重新关联到 /sys/fs/cgroup/memory 这个层级。

3. 资源控制子系统

我们继续来介绍 资源控制子系统 (下面简称子系统) 这个重要的概念。

在 设计一个简单的 cgroup 例子中，主要以内存资源作为分析对象。但我们知道，计算机不单止只有内存资源，还有譬如 CPU、硬盘和网络等资源。所以，cgroup 不单止要控制内存资源的使用，还要控制 CPU、硬盘和网络等资源的使用。如下图所示：

（图7）

在上面的实例中，我们使用一个计数器来统计进程组对内存资源的使用情况，每个 控制组 都需要一个这样的计数器来统计和限制进程组对内存资源的使用。

在 Linux 内核中也有类似的 “计数器“，使用 cgroup_subsys_state 结构来表示（我们称它为 资源统计对象），其定义如下：

struct cgroup_subsys_state {
    struct cgroup *cgroup; // 指向控制组对象
    atomic_t refcnt;       // 引用计数器
    unsigned long flags;   // 标志位
};

cgroup_subsys_state 结构看起来非常简单，这只是表面现象。内核为了将所有的 资源统计对象 抽象化（也就是都能用 cgroup_subsys_state 指针来指向所有类型的 资源统计对象），才定义出这个通用的部分，实际上的 资源统计对象 是比较复杂的。

例如内存的 资源统计对象 定义如下：

struct mem_cgroup {
    // 资源统计对象通用部分
    struct cgroup_subsys_state css;

    // 资源统计对象私有部分
    struct res_counter res;  // 用于统计进程组的内存使用情况
    struct mem_cgroup_lru_info info;
    int prev_priority;
    struct mem_cgroup_stat stat;
};

mem_cgroup 结构与 cgroup_subsys_state 结构的关系如下图所示：

（图8）

资源统计对象 必须与 控制组 绑定，才能实现限制 控制组 对资源的使用。前面我们了解到 cgroup 结构中有个名为 subsys 的字段，如下代码所示：

struct cgroup {
    ...
    // 当前控制组关联的资源统计对象
    struct cgroup_subsys_state *subsys[CGROUP_SUBSYS_COUNT]; 
    ...
};

可以看出，subsys 字段是一个 cgroup_subsys_state 结构的数组，数组的大小为系统支持的 资源控制子系统 数（也就是说，数组上的每个槽位对应着一个子系统资统计对象）。如下图所示：

（图9）

在 Linux 内核中，一个进程可以属于多个 控制组，而每个 控制组 又关联着一个或多个 资源统计对象。所以，一个进程所关联的 资源统计对象 是其所在 控制组 关联的 资源统计对象 的集合。这句话有点难懂，我们用一幅图来说明：

（图10）

如上图所示：

• 进程A 属于控制组 /sys/fs/cgroup/memory/cgrp1/cgrp3 和控制组 /sys/fs/cgroup/cpu/cgrp2/cgrp3，所以 进程A 就关联了 mem_group A 和 task_group A 这两个资源统计对象。

• 进程B 属于控制组 /sys/fs/cgroup/memory/cgrp1/cgrp4 和控制组 /sys/fs/cgroup/cpu/cgrp2/cgrp3，所以 进程B 就关联了 mem_group B 和 task_group A 这两个资源统计对象。

进程通过 css_set 结构来收集不同控制组的 资源统计对象，其定义如下：

struct css_set {
    ...
    // 用于收集不同控制组的资源统计对象
    struct cgroup_subsys_state *subsys[CGROUP_SUBSYS_COUNT];
};

在 进程描述符结构（task_struct） 中有个指向 css_set 结构的指针，如下所示：

struct task_struct {
    ...
    struct css_set *cgroups;
    ...
};

所以，当把一个进程添加到一个 控制组 时，将会把 控制组 关联的 资源统计对象 添加到进程的 cgroups 字段中，从而使进程受到这些 资源统计对象 的限制，结合图10就比较容易理解了。

另外，资源子系统必须关联到某个层级才能起到限制 控制组 使用的目的。每种资源子系统都由一个名为 cgroup_subsys 的结构来描述，其定义如下：

struct cgroup_subsys {
    struct cgroup_subsys_state *(*create)(struct cgroup_subsys *ss, 
                                          struct cgroup *cgrp);
    ...
    void (*attach)(struct cgroup_subsys *ss, struct cgroup *cgrp,
                   struct cgroup *old_cgrp, struct task_struct *tsk);
    void (*fork)(struct cgroup_subsys *ss, struct task_struct *task);
    void (*exit)(struct cgroup_subsys *ss, struct task_struct *task);
    ...
    int subsys_id;
    int active;
    int disabled;
    int early_init;
    const char *name;            // 子系统名字
    struct cgroupfs_root *root;  // 关联的层级根节点
    struct list_head sibling;
    void *private;
};

从 cgroup_subsys 结构的定义可以看出，其主要定义了一些方法和关联的层级。比如：create 方法主要用于当新建一个 控制组 时，创建一个新的 资源统计对象 与其关联；而 root 字段指向关联的层级根节点。

如内存子系统的定义如下：

// 定义在文件：./mm/memcontrol.c

struct cgroup_subsys mem_cgroup_subsys = {
    .name        = "memory",
    .subsys_id   = mem_cgroup_subsys_id,
    .create      = mem_cgroup_create,
    .pre_destroy = mem_cgroup_pre_destroy,
    .destroy     = mem_cgroup_destroy,
    .populate    = mem_cgroup_populate,
    .attach      = mem_cgroup_move_task,
    .early_init  = 0,
};

总结

本文主要分析了 cgroup 的设计与源码实现，不过聪明的读者可能发现本文并没有分析 cgroup 的逻辑代码。

是的，本文并没有分析具体的逻辑代码实现。不过按照本文的设计分析，相信读者能够很容易看到 cgroup 的逻辑代码实现，有兴趣的读者可以自行阅读源代码。