从cgroup_init_early函数学习cgroup——框架

一些概念的理解

---

cgroup
cgourp是一种机制
作用：集成各个进程，对进程分组实现进程组，分配或限制进程组使用的资源（这部分主要有个各个subsystem完成）。
另一个角度，在研究代码的时候，我们更愿意将cgroup理解为一种控制资源的行为。比如：我想要控制进程的CPU使用率为20%，那么我可以创建一个cgroup，这cgroup的作用就是控制指定进程的cpu使用率为20%。

---

subsystem：
不同subsystem对应控制不同的资源：

cpu subsystem：指定进程组能使用的CPU；memmory subsystem：指定进程组能使用的内存量，并编写内存使用量报告；cpuset subsystem：指定进程组能使用的各CPU和节点集；freezer subsystem：可停止进程组状态或启动；cpuacct subsystem：对进程组使用的CPU资源编写报告；blkio：设置对模块设备的输入输出限制；devices：设置进程组能使用的设备；

查看cgroup subsystem：

yin123@yin:~$ ls /sys/fs/cgroup/cpu  cpuacct  devices  freezer  memory

---

框架
概括描述cgroup框架
在这部分，我们试图用一种比较形象的描述和思维来概括cgroup的框架，不涉及代码。
为了方便理解，在开始所有的分析之前，必须要明确一点：cgroup是有层次结构的
所有的cgroup以树状分层（hierarchy）的形式被组织在一起。
你自然会觉得疑问，既然每个cgroup对应一种控制行为或者说功能，那么father cgroup和children cgroups是什么关系呢？
还是拿上面的例子: 整个cpu占用为100%.这就是根,也就是hierarchy.然后,cgroup A设置cpu占用20%,cgroup B点用50%,cgroup A和cgroup B就是它下面的子层cgroup.（这个问题的解答摘录自http://blog.chinaunix.net/uid-23010930-id-2974762.html）

OK，现在假设在我们面前有这样的一些cgroup

        group A                                 group 1                        group B          group C                group 2          group 3

A和1分别代表不同的控制行为，BC和23分别是A和1的children group。
为了更好的组织所有的cgroup，我们建立了一个top_cgroup，作为A和1的father cgroup，于是就成了这样：

                            top_cgroup        group A                                 group 1                        group B          group C                group 2          group 3

这样，所有的cgroup就建立了联系。

还有一个问题，试想，groupB作为一个控制行为，它可能想控制进程的CPU使用率和内存使用量，那么就涉及到了两个subsystem：CPU和memory。
我们前面提到了很多subsystem，对应不同的资源，可供各个cgroup使用。
那么group B该如何高效快速地找到需要的subsystem呢？将group B与这两个subsystem建立联系。
于是我们就想到了top_cgroup，所有的cgroup都和top_cgroup联系起来，如果top_cgroup与所有的subsystem联系起来，那么就OK了。
首先，把所有的subsystem作成一个双向链表，形如：

subsys_list--|             |cgroup_subsys 1 <---> cgroup_subsys 2 <---> cgroup_subsys 3 <---> cgroup_subsys 4        |                                                             |        |<----------------------------------------------------------->|

现在要做的就是将subsys_list与top_cgroup建立联系，很简单，把他们作为成员放到同一个结构体当中。
我们把这个结构体叫做cgroupfs_root，形如：

                 ____________                |  ......    |                |____________|                |.subsys_list|                |____________|<————————top_cgroup                |.root       |                |.top_cgroup |                  |____________|

到这里，似乎一切都很清晰了，然而，问题才刚刚开始：
cgroup的最终目的是：管理进程组，控制进程组的资源。
这涉及到两个问题：
1.cgroup要管理拿些进程？
2.管理进程的哪些资源？
对于问题1，涉及到进程与cgroup的关系。
对于问题2，涉及到进程与cgroup_subsys的关系。
要解决这两个问题，让我们进入代码，看内核是如何实现的。

---

数据结构

这一部分，我们将结合之前的分析，来看内核相关数据结构。
进程需要与cgroup以及subsystem建立联系，关键在于css_set结构体。
首先，每个进程都可以对应一个css_set结构体：
进程对应一个task_struct结构体，每个task_struct结构体中有一个css_set类型的成员指针cgroups

struct task_struct {......#ifdef CONFIG_CGROUPS    /* Control Group info protected by css_set_lock */    struct css_set __rcu *cgroups;    /* cg_list protected by css_set_lock and tsk->alloc_lock */    struct list_head cg_list;#endif......}

cgroups指针指向进程对应的css_set结构体，css_set结构体定义如下

/* * A css_set is a structure holding pointers to a set of * cgroup_subsys_state objects. This saves space in the task struct * object and speeds up fork()/exit(), since a single inc/dec and a * list_add()/del() can bump the reference count on the entire cgroup * set for a task. */struct css_set {    /* Reference count */    atomic_t refcount;        //引用计数    /*     * List running through all cgroup groups in the same hash     * slot. Protected by css_set_lock     */    struct hlist_node hlist;      //hash表相关    /*     * List running through all tasks using this cgroup     * group. Protected by css_set_lock     */    struct list_head tasks;  //与该css_set关联的task链表    /*     * List of cgrp_cset_links pointing at cgroups referenced from this     * css_set.  Protected by css_set_lock.     */    struct list_head cgrp_links;  //与该css_set关联的cgrp_cset_links的链表，后面会讲到    /*     * Set of subsystem states, one for each subsystem. This array     * is immutable after creation apart from the init_css_set     * during subsystem registration (at boot time) and modular subsystem     * loading/unloading.     */    struct cgroup_subsys_state *subsys[CGROUP_SUBSYS_COUNT];    /* For RCU-protected deletion */    struct rcu_head rcu_head;};

css_set结构体中struct cgroup_subsys_state *subsys[CGROUP_SUBSYS_COUNT];指针数组，保存了对应进程所属于（或者使用）的subsystem的设置信息，可快速浏览已设置的 subsystem。
cgroup_subsys_state的定义如下：

/* Per-subsystem/per-cgroup state maintained by the system. */struct cgroup_subsys_state {    /* the cgroup that this css is attached to */    struct cgroup *cgroup;    /* the cgroup subsystem that this css is attached to */    struct cgroup_subsys *ss;    /* reference count - access via css_[try]get() and css_put() */    struct percpu_ref refcnt;    /* the parent css */    struct cgroup_subsys_state *parent;    unsigned long flags;    /* percpu_ref killing and RCU release */    struct rcu_head rcu_head;    struct work_struct destroy_work;};

每个cgroup_subsys对应一个cgroup_subsys_state，通过cgroup_subsys_state的ss指针可以找到该css对应的cgroup_subsys。
所以每个进程可以有自己的css_set结构体（由进程的.cgroups指向），css_set结构体中有对应的cgroup_subsys_state指针数组，通过cgroup_subsys_state可以找到对应的cgroup_subsys。
如此，进程与cgroup_subsys的联系就建立了。第二个问题解决。
那么进程如何与cgroup建立联系？
内核定义了一个结构体叫做cgrp_cset_link

/* * A cgroup can be associated with multiple css_sets as different tasks may * belong to different cgroups on different hierarchies.  In the other * direction, a css_set is naturally associated with multiple cgroups. * This M:N relationship is represented by the following link structure * which exists for each association and allows traversing the associations * from both sides. */struct cgrp_cset_link {    /* the cgroup and css_set this link associates */    struct cgroup       *cgrp;    struct css_set      *cset;    /* list of cgrp_cset_links anchored at cgrp->cset_links */    struct list_head    cset_link;    /* list of cgrp_cset_links anchored at css_set->cgrp_links */    struct list_head    cgrp_link;};

先看一下注释：
一个cgroup可能关联多个css_sets，因为不同进程可能属于不同的cgroup（即对不同的进程可能使用了相同的控制行为）。
另一方面，一个css_set通常关联多个cgroup（即对一个进程使用多个控制行为）。
cgroup和css_set的这种M：N的对应关系可以用struct cgrp_cset_link结构体表示，该结构体用于连接css_set与cgroup。
现在基本上搞清了cgroup的架构，来看代码。