cgroup
cgroup从2.6.4引入linux内核主线，目前默认已启用该特性。在cgroup出现之前，只能对一个进程做资源限制，比如通过sched_setaffinity设置进程cpu亲和性，使用ulimit限制进程打开文件上限、栈大小等。
cgroups是Linux下控制一个（或一组）进程的资源限制机制，全称是control groups，可以对cpu、内存等资源做精细化控制，比如目前很多的Docker在Linux下就是基于cgroups提供的资源限制机制来实现资源控制的；除此之外，开发者也可以指直接基于cgroups来进行进程资源控制，比如8核的机器上部署了一个web服务和一个计算服务，可以让web服务仅可使用其中6个核，把剩下的两个核留给计算服务。cgroups cpu限制除了可以限制使用多少/哪几个核心之外，还可以设置cpu占用比（注意占用比是各自都跑满情况下的使用比例，如果一个cgroup空闲而另一个繁忙，那么繁忙的cgroup是有可能占满整个cpu核心的）。
本文主要讨论下cgroups概念及原理，然后分析下cgroups文件系统概念，最后对cgroups做个总结，关于cgroups的使用实践可以参考网上资料，这里不再赘述。
cgroups概念
从实现角度来看，cgroups实现了一个通用的进程分组框架，不同资源的具体管理工作由各cgroup子系统来实现，当需要多个限制策略比如同时针对cpu和内存进行限制，则同时关联多个cgroup子系统即可。
cgroups子系统
cgroups为每种资源定义了一个子系统，典型的子系统如下：
cpu 子系统，主要限制进程的 cpu 使用率。
cpuacct 子系统，可以统计 cgroups 中的进程的 cpu 使用报告。
cpuset 子系统，可以为 cgroups 中的进程分配单独的 cpu 节点或者内存节点。
memory 子系统，可以限制进程的 memory 使用量。
blkio 子系统，可以限制进程的块设备 io。
devices 子系统，可以控制进程能够访问某些设备。
net_cls 子系统，可以标记 cgroups 中进程的网络数据包，然后可以使用 tc 模块（traffic control）对数据包进行控制。
freezer 子系统，可以挂起或者恢复 cgroups 中的进程。
ns 子系统，可以使不同 cgroups 下面的进程使用不同的 namespace。
每个子系统都是定义了一套限制策略，它们需要与内核的其他模块配合来完成资源限制功能，比如对 cpu 资源的限制是通过进程调度模块根据 cpu 子系统的配置来完成的；对内存资源的限制则是内存模块根据 memory 子系统的配置来完成的，而对网络数据包的控制则需要 Traffic Control 子系统来配合完成。
cgroups原理
关于cgroups原理，可以从进程角度来剖析相关数据结构之间关系，Linux 下管理进程的数据结构是 task_struct，其中与cgrups相关属性如下：
// task_struct代码
#ifdef CONFIG_CGROUPS
/* Control Group info protected by css_set_lock /
struct css_set *cgroups;
/ cg_list protected by css_set_lock and tsk->alloc_lock */
struct list_head cg_list;
#endif
每个进程对应一个css_set结构，css_set存储了与进程相关的cgropus信息。cg_list是一个嵌入的 list_head 结构，用于将连到同一个 css_set 的进程组织成一个链表。进程和css_set的关系是多对一关系，tasks表示关联的多个进程。
struct css_set {
atomic_t refcount;
struct hlist_node hlist;
struct list_head tasks;
struct list_head cg_links;
struct cgroup_subsys_state *subsys[CGROUP_SUBSYS_COUNT];
struct rcu_head rcu_head;
};
subsys 是一个指针数组，存储一组指向 cgroup_subsys_state 的指针，通过这个指针进程可以获取到对应的cgroups信息，一个 cgroup_subsys_state 就是进程与一个特定子系统相关的信息，cgroup_subsys_state结构体如下：
struct cgroup_subsys_state {
struct cgroup *cgroup;
atomic_t refcnt;
unsigned long flags;
struct css_id *id;
};
cgroup 指针指向了一个 cgroup 结构，也就是进程属于的 cgroup，进程受到子系统控制就是加入到特定的cgroup来实现的，就是对应这里的cgroup，由此看出进程和cgroup的关系是多对多关系。
struct cgroup {
unsigned long flags;
atomic_t count;
struct list_head sibling;
struct list_head children;
struct cgroup *parent;
struct dentry *dentry;
struct cgroup_subsys_state *subsys[CGROUP_SUBSYS_COUNT];
struct cgroupfs_root *root;
struct cgroup *top_cgroup;
struct list_head css_sets;
struct list_head release_list;
struct list_head pidlists;
struct mutex pidlist_mutex;
struct rcu_head rcu_head;
struct list_head event_list;
spinlock_t event_list_lock;
};
sibling、children 和 parent 三个嵌入的 list_head 负责将统一层级的 cgroup 连接成一棵 cgroup 树。subsys 是一个指针数组，存储一组指向 cgroup_subsys_state 的指针。这组指针指向了此 cgroup 跟各个子系统相关的信息，也就是说一个cgroup可以关联多个子系统，二者关系是多对多关系。
Linux下的cgroups的数据结构图示如下：
cgroups 层级结构
在cgrups中一个task任务就是一个进程，一个进程可以加入到某个cgroup，也从一个进程组迁移到另一个cgroup。一个进程组的进程可以使用 cgroups 以控制族群为单位分配的资源，同时受到 cgroups 以控制族群为单位设定的限制。多个cgroup形成一个层级结构（树形结构），cgroup树上的子节点cgroup是父节点cgroup的孩子，继承父cgroup的特定的属性。注意：cgroups层级只会关联某个子系统之后才能进行对应的资源控制，一个子系统附加到某个层级以后，这个层级上的所有cgroup都受到这个子系统的控制。cgroup典型应用架构图如下：
cgroups文件系统
Linux 使用了多种数据结构在内核中实现了 cgroups 的配置，关联了进程和 cgroups 节点，那么 Linux 又是如何让用户态的进程使用到 cgroups 的功能呢？ Linux内核有一个很强大的模块叫 VFS (Virtual File System)。 VFS 能够把具体文件系统的细节隐藏起来，给用户态进程提供一个统一的文件系统 API 接口。 cgroups 也是通过 VFS 把功能暴露给用户态的，cgroups 与 VFS 之间的衔接部分称之为 cgroups 文件系统。通过cgroups适配VFS，用户可以使用VFS接口来操作cgroup功能。
VFS 是一个内核抽象层（通用文件模型），能够隐藏具体文件系统的实现细节，从而给用户态进程提供一套统一的 API 接口。VFS 使用了一种通用文件系统的设计，具体的文件系统只要实现了 VFS 的设计接口，就能够注册到 VFS 中，从而使内核可以读写这种文件系统。 这很像面向对象设计中的抽象类与子类之间的关系，抽象类负责对外接口的设计，子类负责具体的实现。其实，VFS本身就是用 c 语言实现的一套面向对象的接口。
小结
cgroups是Linux下控制一个（或一组）进程的资源限制机制，cgroup通过关联单个/多个子系统定义了一套限制策略来限制CPU/内存等资源，子系统上限制策略相当于一套配置，需要内核中对应模块配合来完成资源限制功能，比如对 cpu 资源的限制是通过进程调度模块根据 cpu 子系统的配置来完成的等。
注意cgroups资源限制是针对cgroup为单位的，不管cgroup下是有一个进程还是多个进程。Docker下的容器内所有进程就是属于同一组cgroup管理之下的，比如限制CPU使用，限制内存大小等
linux的cgroup系统可谓是一个典范，它轻量地实现了诸如solaris的“容器”的概念，也许也是对linux本身“命名空间”的一种冲击。它是分层的，也可以说是树形的结构，一个“控制组”拥有一个ROOT，每一个ROOT控制一组元素，在这个ROOT当中可以建立很多的“组”(cgroup)，每一个组还可以建立下级的组…。每新建一个cgroup必须确定一组它关心的cgroup_subsys，比如cpuset，memory，ns等，怎么确定呢？这是通过文件系统的mount实现的，当你执行：
mount -t cgroup cgroup -o cpuset memory my
的时候，你就建立一个ROOT，这个ROOT包含所有的进程，然后你可以在my目录中执行mkdir group1 group2，这样就建立了两个cgroup，实际上，当你mount的时候，系统就建立了一个虚拟的组group-root，如果你执行cat my/tasks，你会发现它包含了所有的进程，如果你执行cat my/group1/tasks，你会发现它是空的，因为还没有任何的进程被加入进去。现在执行echo 761>my/group1/tasks，那么pid为761的进程将被加入到group1，通过修改group1目录下的文件就可以对这个group1中当前tasks文件中包含的所有的进程进行控制了。这一切是如何实现的？实际上linux内核代码的cgroup子系统实现了类似数据库的结构，包括表结构和查询引擎，通过阅读代码可以看出，每一个进程task包含一个css_set类型的字段：
struct css_set {
struct kref ref;
struct hlist_node hlist;
struct list_head tasks; //解决冗余，包含所有使用这个set的进程
struct list_head cg_links; //解决冗余，包含所有参与管理这个set的cgroup。
struct cgroup_subsys_state subsys[CGROUP_SUBSYS_COUNT];
};
既然它被一组subsys控制，为何不直接将每个subsys本身包含在task中呢？这是为了解决数据冗余的问题，因为其他的进程也可以受这些subsys控制。
有必要说一下上面的css_set结构中的cg_links字段，它包含了所有的参与管理这个set的cgroup，为何会这样呢？难道一个set不是由一个cgroup管理的吗？不是的，要知道管理是基于“一组”subsys的，而这一组并不一定是全部的编译进内核也就是内核支持的subsys。比如你分别用-o参数cpu，memory…mount了5个cgroup文件系统，那么一个进程关联的css_set就会由5个cgroup管理，每一个mount的ROOT会管理一个，这个ROOT会用文件系统的方式管理进程分别属于该ROOT的哪个cgroup。
下面看一下cgroup_subsys_state，这个结构可以看作静态cgroup_subsys结构的动态实例，静态的cgroup_subsys中包含了一些通用的方法，而动态的cgroup_subsys_state则仅仅是一个父类，具体的数据和额外的方法通过继承它来实现，比如：
struct mem_cgroup {
struct cgroup_subsys_state css;
struct res_counter res;
struct mem_cgroup_lru_info info;
int prev_priority; / for recording reclaim priority /
struct mem_cgroup_stat stat;
};
任何时候，只要你得到了一个cgroup_subsys_state，并且根据其subsys_id确认它是关于memory的，那么就可以通过：
static inline struct cgroup_subsys_state *task_subsys_state(
struct task_struct *task, int subsys_id)
{
return rcu_dereference(task->cgroups->subsys[subsys_id]);
}
和
container_of(task_subsys_state(p, mem_cgroup_subsys_id), struct mem_cgroup, css);
来取得这个可被称为子类实例的mem_cgroup，接下来就可以操作它的数据了。终于可以看一下cgroup_subsys_state了：
struct cgroup_subsys_state {
struct cgroup *cgroup;
atomic_t refcnt;
unsigned long flags;
};
这个结构很简单，cgroup是它绑定的一个cgroup实例，从名称上也可以看出cgroup_subsys_state结构是动态的，它表示进程的subsys的state，由于它是被cgroup管理的，因此它也只能有一个cgroup与其绑定。
接下来看一下cgroup结构，这好像是一个重量级的结构，其实不然，它仅仅起到一个粘合的作用，换句话说就是管理者：
struct cgroup {
unsigned long flags;
atomic_t count;
struct list_head sibling; //此和以下几个实现了树型结构
struct list_head children;
struct cgroup *parent;
struct dentry *dentry;
struct cgroup_subsys_state *subsys[CGROUP_SUBSYS_COUNT]; //这里仅包含对应ROOT相关的subsys
struct cgroupfs_root *root; //对应的那个ROOT
struct cgroup *top_cgroup;
struct list_head css_sets; //包含所有的它参与管理的css_set
struct list_head release_list;
}
前面提到过，进程要显式加入一个ROOT的cgroup，在加入的时候可能会为进程绑定一个新的css_set(必须保证css_set的subsys数组完全相同才能重用，如果之前没有这样的css_set建立，只好新建立一个)，只要绑定了一个新的css_set，这个set就要加入到cgroup的css_sets链表中，最简单的可以在css_set中添加一个字段用于此目的，与此同时cgroup中也要增加一个list_head结构用来链接css_set的cg_links字段，这样做为何不好呢？它增加了两个数据结构的耦合性，同时也增加了数据的冗余性，因为一个cgroup的ROOT负责一组subsys，一个进程也是和一组subsys关联，因此只需要一个进程的一组subsys中被同一个ROOT管理的第一个加入到cgroup链表中就可以表示一个进程受到了这个cgroup的管理，比如进程p1加入group1，该group1的ROOT管理cpu和memory，那么其css_set的subsys数组中只需要cpu_id的这个subsys加入cgroup的css_sets链表就可以了，为了代码的简单，因此引入了一个中间结构，那就是cg_cgroup_link：
struct cg_cgroup_link {
struct list_head cgrp_link_list; //代表一个css_set加入到cgroup
struct list_head cg_link_list; //代表一个cgroup加入到css_set
struct css_set *cg; //指回css_set
… //后续的内核还要指回cgroup，这里的内核是2.6.26
};
在此必须说一下为何要有cg_cgroup_link这个结构体。如果在css_set中和cgroup中直接加入链表元素是解决不了多对多问题的，比如所有参与管理一个css_set的cgroup都将其链表元素加入 css_set的链表，反过来css_set的链表元素也应该加入一个cgroup的链表，代表它是该cgroup管理的css_set之一，现在问题来了，前面说过一个css_set可以属于很多ROOT，那么它到底加入哪个cgroup的链表呢？毕竟css_set和cgroup之间是如此单项一对多的关系耦合，因此解除耦合的办法就是设计一个中间结构，那就是cg_cgroup_link。
很多时候，很多人在网上写了一大堆关于分析“linux内核”的文章，很多文章都是仅仅分析代码流程，但是很少有文章能说明为何这么做(除非文章的作者着手提交一个补丁或者其它…)。其实linux内核就是一个数据库设计的教程，它不但展示了表结构，而且还有查询引擎，故而linux内核绝对是绝妙的哦！比如在input子系统中，input_handle这个结构体也是和cg_cgroup_link意义一样的，也是为了解决多对多的问题而设置的，还有一个明显的例子，那就是linux内核中的总线驱动架构。
由此看来，学习linux内核可以学到两大当今时髦的东西，一个就是OO，另一个就是数据库的设计，千万不要以为linux内核仅仅是底层的东西，搞应用的人不用学习，其实各个领域是相通的，我相信，当一个顶级的文学家听说了广义相对论的时候，他也一定会提出一些自己的看法的。我经常看历史著作，那些作者们看起来对任何领域都很感兴趣…
附：看一下cgroup的静态数据结构们吧
首先看一下一个静态的超类，那就是cgroup_subsys，它包含了一系列的接口，但是没有实现！
struct cgroup_subsys {
struct cgroup_subsys_state *(create)(struct cgroup_subsys *ss,
struct cgroup *cgrp);
…//类似的接口
int subsys_id;
int active;
int disabled;
int early_init;
#define MAX_CGROUP_TYPE_NAMELEN 32
const char *name;
struct cgroupfs_root *root;
struct list_head sibling; //用于挂载一系列的state
void *private; //用于扩展
};
每一个挂载(mount)的cgroup文件系统都有一个cgroupfs_root实例：
struct cgroupfs_root {
struct super_block *sb;
unsigned long subsys_bits;
unsigned long actual_subsys_bits;
struct list_head subsys_list; //本ROOT关注的subsys
struct cgroup top_cgroup;
int number_of_cgroups;
struct list_head root_list;
unsigned long flags;
char release_agent_path[PATH_MAX];
};
