來源: http://blog.chinaunix.net/u1/51562/showart_1736813.html
Kernel doc.: http://www.mjmwired.net/kernel/Documentation/cgroups.txt


------------------------------------------

: 前言

前段時間,一直在寫作業系統和研究Solaris kernel.從而對linux kernel關心甚少.不久前偶然收到富士通的面試,由於諸多原因推辭掉了這次機會.不過招聘要求給我留下了較深的印像.其中涉及到了cgroup機制.cgroup對我來說並不陌生,LKML上看到過它的path.2008 AKA大會上也有人對它做為專題分析.不過一直都沒有深入代碼研究.這段時間打算將kernel中新加的功能整理一下,就先從cgroup開始吧.

Cgroup是近代linux kernel出現的.它為process和其後續的子process提供了一種性能控制機制.在這裡不打算對cgroup的作用和使用做過多的描述.本文從linux kernel的源代碼出發分析cgroup機制的相關實現.在本節中,主要分析cgroup的框架實現.在後續的部份再來詳細分析kernel中的幾個重要的subsystem.關於cgroup的使用和介紹可以查看linux-2.6.28-rc7/Documentation/cgroups/cgroup.txt.另外,本文的源代碼分析基於linux kernel 2.6.28版本.分析的源文件基本位於inux-2.6.28-rc7/kernel/cgroup.cinux-2.6.28-rc7/kernel/debug_cgroup.c.

:cgroup中的概念

在深入到cgroup的代碼分析之前.先來瞭解一下cgroup中涉及到的幾個概念:

1:cgroup: 它的全稱為control group.即一組process的行為控制.比如,我們限制process/bin/shCPU使用為20%.我們就可以建一個cpu佔用為20%cgroup.然後將/bin/shprocess添加到這個cgroup.當然,一個cgroup可以有多個process.

2:subsystem: 它類似於我們在netfilter中的過濾hook.比如上面的CPU佔用率就是一個subsystem.簡而言之.subsystem就是cgroup中可添加刪除的模塊.cgroup架構的封裝下為cgroup提供多種行為控制.subsystem在下文中簡寫成subsys.

3: hierarchy: 它是cgroup的集合.可以把它理解成cgroup的根.cgrouphierarchy的結點.還是拿上面的例子: 整個cpu佔用為100%.這就是根,也就是hierarchy.然後,cgroup A設置cpu佔用20%,cgroup B點用50%,cgroup Acgroup B就是它下面的子層cgroup.

:cgroup中的重要資料結構

我們先來看cgroup的使用.有三面一個例子:

[root@localhost cgroups]# mount -t cgroup cgroup -o debug /dev/cgroup

[root@localhost cgroups]# mkdir /dev/cgroup/eric_test

如上所示,debug subsystem做的一個測試. /dev/cgroupdebug subsys的掛載點.也就是我們在上面所分析的hierarchy.然後在hierarchy下又創建了一個名為eric_testcgroup.

kernel的源代碼中.掛載目錄,也就是cgroup的根目錄用資料結構struct cgroupfs_root表示.cgroupstruct cgroup表示.

分別來看一下這兩個結構的含義,struct cgroupfs_root定義如下:

struct cgroupfs_root {

//cgroup文件系統的超級塊

   struct super_block *sb;

 

    /*

     * The bitmask of subsystems intended to be attached to this

     * hierarchy

     */

     //hierarchy相關聯的subsys 位圖

    unsigned long subsys_bits;

 

    /* The bitmask of subsystems currently attached to this hierarchy */

    //當前hierarchy 中的subsys位圖

    unsigned long actual_subsys_bits;

 

    /* A list running through the attached subsystems */

    //hierarchy中的subsys鏈表

    struct list_head subsys_list;

 

    /* The root cgroup for this hierarchy */

    //hierarchy中的頂層cgroup

    struct cgroup top_cgroup;

 

    /* Tracks how many cgroups are currently defined in hierarchy.*/

    //hierarchycgroup的數目

    int number_of_cgroups;

 

    /* A list running through the mounted hierarchies */

    //用來鏈入全局鏈表roots

    struct list_head root_list;

 

    /* Hierarchy-specific flags */

    //hierarchy的標誌

    unsigned long flags;

 

    /* The path to use for release notifications. */

    char release_agent_path[PATH_MAX];

};

注意cgroupfs_root中有個struct cgroup結構的成員:top_cgroup.即在每個掛載點下面都會有一個總的cgroup.而通過mkdir創建的cgroup是它的子結點.

其中,release_agent_path[ ]的成員含義.我們在後面再來詳細分析.

 

Struct cgroup的定義如下:

struct cgroup {

    //cgroup的標誌

    unsigned long flags;        /* "unsigned long" so bitops work */

 

    /* count users of this cgroup. >0 means busy, but doesn't

     * necessarily indicate the number of tasks in the

     * cgroup */

     //引用計數

    atomic_t count;

 

    /*

     * We link our 'sibling' struct into our parent's 'children'.

     * Our children link their 'sibling' into our 'children'.

     */

     //用來鏈入父結點的children鏈表

    struct list_head sibling;   /* my parent's children */

    //子結點鏈表

    struct list_head children;  /* my children */

    //cgroup的父結點

    struct cgroup *parent;  /* my parent */

    //cgroup所處的目錄

    struct dentry *dentry;      /* cgroup fs entry */

 

    /* Private pointers for each registered subsystem */

    struct cgroup_subsys_state *subsys[CGROUP_SUBSYS_COUNT];

    //cgroup所屬的cgroupfs_root

    struct cgroupfs_root *root;

    //掛載目錄下的最上層cgroup

    struct cgroup *top_cgroup;

    ……

……

}

上面並沒有將cgroup的結構全部都列出來.其它的全部我們等遇到的時候再來進行分析.

其實,struct cgroupfs_rootstruct cgroup就是表示了一種空間層次關係,它就對應著掛著點下面的文件示圖.

 

在上面說過了,cgroup表示process的行為控制.因為subsys必須要知道process是位於哪一個cgroup.

所以.struct task_structcgroup中存在一種映射.

Cgroupstruct task_struct中增加了兩個成員,如下示:

struct 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

    ……

    ……

}

注意struct task_struct中並沒有一個直接的成員指向cgroup,而是指向了css_set.css_set的結構如下:

struct css_set {

    //css_set引用計數

    atomic_t refcount;

//哈希指針.指向css_set_table[ ]

    struct hlist_node hlist;

//css_set關聯的task鏈表

    struct list_head tasks;

    //css_set關聯的cg_cgroup_link鏈表

    struct list_head cg_links;

//一組subsystem states.subsys->create()創建而成

    struct cgroup_subsys_state *subsys[CGROUP_SUBSYS_COUNT];

}

那從css_set怎麼轉換到cgroup? 再來看一個輔助的資料結構.struct cg_cgroup_link.它的定義如下:

struct cg_cgroup_link {

    /*

     * List running through cg_cgroup_links associated with a

     * cgroup, anchored on cgroup->css_sets

     */

    struct list_head cgrp_link_list;

    /*

     * List running through cg_cgroup_links pointing at a

     * single css_set object, anchored on css_set->cg_links

     */

    struct list_head cg_link_list;

    struct css_set *cg;

};

如上所示.它的cgrp_link_list鏈入到了cgroup->css_sets. Cg_link_list鏈入到css_set->cg_links.

其中.cg就是批向cg_link_list所指向的css_set.

 

上面分析的幾個資料結構關係十分複雜.聯繫也十分緊密.下面以圖示的方式直觀將各結構的聯繫表示如下:

 

注意上圖中的css_set_table[ ].它是一個哈希數組.用來存放struct css_set.它的哈希函數為css_set_hash().所有的衝突項都鏈入數組對應項的hlist.

 

:cgroup初始化

Cgroup的初始化包括兩個部份.cgroup_init_early()cgroup_init().分別表示在系統初始時的初始化和系統初始化完成時的初始化.分為這兩個部份是因為有些subsys是要在系統剛啟動的時候就必須要初始化的.

 

4.1: cgroup_init_early()

先看cgroup_init_early()的代碼:

int __init cgroup_init_early(void)

{

    int i;

    //初始化全局量init_css_set

    atomic_set(&init_css_set.refcount, 1);

    INIT_LIST_HEAD(&init_css_set.cg_links);

    INIT_LIST_HEAD(&init_css_set.tasks);

    INIT_HLIST_NODE(&init_css_set.hlist);

    //css_set_count:系統中struct css_set計數

    css_set_count = 1;

    //初始化全局變量rootnode

    init_cgroup_root(&rootnode);

    //將全局變量rootnode添加到roots鏈表

    list_add(&rootnode.root_list, &roots);

    root_count = 1;

    //使系統的初始化processcgroup指向init_css_set

    init_task.cgroups = &init_css_set;

    //init_css_setrootnode.top_cgroup關聯起來

    init_css_set_link.cg = &init_css_set;

    list_add(&init_css_set_link.cgrp_link_list,

         &rootnode.top_cgroup.css_sets);

    list_add(&init_css_set_link.cg_link_list,

         &init_css_set.cg_links);

    //初始化css_set_table[ ]

    for (i = 0; i < CSS_SET_TABLE_SIZE; i++)

        INIT_HLIST_HEAD(&css_set_table[i]);

    //對一些需要在系統啟動時初始化的subsys進行初始化

    for (i = 0; i < CGROUP_SUBSYS_COUNT; i++) {

        struct cgroup_subsys *ss = subsys[i];

 

        BUG_ON(!ss->name);

        BUG_ON(strlen(ss->name) > MAX_CGROUP_TYPE_NAMELEN);

        BUG_ON(!ss->create);

        BUG_ON(!ss->destroy);

        if (ss->subsys_id != i) {

            printk(KERN_ERR "cgroup: Subsys %s id == %d\n",

                   ss->name, ss->subsys_id);

            BUG();

        }

 

        if (ss->early_init)

            cgroup_init_subsys(ss);

    }

    return 0;

}

這裡主要是初始化init_task.cgroup結構.伴隨著它的初始化.相繼需要初始化rootnodeinit_css_set.接著,又需要初始化init_css_set_linkrootnode.top_cgroupinit_css_set關聯起來.

接著初始化了哈希數組css_set_table[]並且將一些需要在系統剛啟動時候需要初始化的subsys進行初始化.

從上面的代碼可以看到.系統中的cgroup subsystem都存放在subsys[].定義如下:

static struct cgroup_subsys *subsys[] = {

#include <linux/cgroup_subsys.h>

}

即所有的subsys都定義在linux/cgroup_subsys.h.

 

對照之前分析的資料結構,應該不難理解這段代碼.下面來分析一下里面所遇到的一些重要的子函數.

 

Init_cgroup_root()代碼如下:

static void init_cgroup_root(struct cgroupfs_root *root)

{

    struct cgroup *cgrp = &root->top_cgroup;

    INIT_LIST_HEAD(&root->subsys_list);

    INIT_LIST_HEAD(&root->root_list);

    root->number_of_cgroups = 1;

    cgrp->root = root;

    cgrp->top_cgroup = cgrp;

    init_cgroup_housekeeping(cgrp);

}

它先初始化root中的幾條鏈表.因為root中有一個top_cgroup.因此將root->number_of_cgroups置為1.然後,root->top_cgroup進行初始化.使root->top_cgroup.root指向root. root->top_cgroup.top_cgroup指向它的本身.因為root->top_cgroup就是目錄下的第一個cgroup.

最後在init_cgroup_housekeeping()初始化cgroup的鏈表和讀寫鎖.

 

Cgroup_init_subsys()代碼如下:

static void __init cgroup_init_subsys(struct cgroup_subsys *ss)

{

    struct cgroup_subsys_state *css;

 

    printk(KERN_INFO "Initializing cgroup subsys %s\n", ss->name);

 

    /* Create the top cgroup state for this subsystem */

    ss->root = &rootnode;

    css = ss->create(ss, dummytop);

    /* We don't handle early failures gracefully */

    BUG_ON(IS_ERR(css));

    init_cgroup_css(css, ss, dummytop);

 

    /* Update the init_css_set to contain a subsys

     * pointer to this state - since the subsystem is

     * newly registered, all tasks and hence the

     * init_css_set is in the subsystem's top cgroup. */

    init_css_set.subsys[ss->subsys_id] = dummytop->subsys[ss->subsys_id];

 

    need_forkexit_callback |= ss->fork || ss->exit;

    need_mm_owner_callback |= !!ss->mm_owner_changed;

 

    /* At system boot, before all subsystems have been

     * registered, no tasks have been forked, so we don't

     * need to invoke fork callbacks here. */

    BUG_ON(!list_empty(&init_task.tasks));

 

    ss->active = 1;

}

dummytop定義如下:

#define dummytop (&rootnode.top_cgroup)

在這個函數中:

1):將每個要註冊的subsys->root都指向rootnode.

2):調用subsys->create()生成一個cgroup_subsys_state.

3):調用init_cgroup_css()dummytop.subsys[i]設置成ss->create()生成的cgroup_subsys_state

4):更新init_css_set->subsys()對應項的值.

5):ss->active設為1.表示它已經初始化了.

 

4.2: cgroup_init()

cgroup_init()cgroup的第二階段的初始化.代碼如下:

int __init cgroup_init(void)

{

    int err;

    int i;

    struct hlist_head *hhead;

 

    err = bdi_init(&cgroup_backing_dev_info);

    if (err)

        return err;

    //將剩下的(不需要在系統啟動時初始化的subsys)subsys進行初始化

    for (i = 0; i < CGROUP_SUBSYS_COUNT; i++) {

        struct cgroup_subsys *ss = subsys[i];

        if (!ss->early_init)

            cgroup_init_subsys(ss);

    }

 

    /* Add init_css_set to the hash table */

    //init_css_set添加到css_set_table[ ]

    hhead = css_set_hash(init_css_set.subsys);

    hlist_add_head(&init_css_set.hlist, hhead);

    //註冊cgroup文件系統

    err = register_filesystem(&cgroup_fs_type);

    if (err < 0)

        goto out;

    //proc文件系統的根目錄下創建一個名為cgroups的文件

    proc_create("cgroups", 0, NULL, &proc_cgroupstats_operations);

 

out:

    if (err)

        bdi_destroy(&cgroup_backing_dev_info);

 

    return err;

}

這個函數比較簡單.首先.它將剩餘的subsys初始化.然後將init_css_set添加進哈希數組css_set_table[ ].在上面的代碼中css_set_hash()css_set_table的哈希函數.它是css_set->subsys為哈希鍵值,css_set_table[ ]中找到對應項.然後調用hlist_add_head()init_css_set添加到衝突項中.

然後,註冊了cgroup文件系統.這個文件系統也是我們在用戶空間使用cgroup時必須掛載的.

最後,proc的根目錄下創建了一個名為cgroups的文件.用來從用戶空間觀察cgroup的狀態.

 

經過cgroup的兩個階段的初始化, init_css_set, rootnode,subsys已經都初始化完成.表面上看起來它們很複雜,其實,它們只是表示cgroup的初始化狀態而已.例如,如果subsys->root等於rootnode,那表示subsys沒有被其它的cgroup所使用.

:父子process之間的cgroup關聯

在上面看到的代碼中.init_task.cgroup設置為了init_css_set.我們知道,init_task是系統的第一個process.所有的過程都是由它創建的.init_task.cgroup到底會在它後面的子process造成什麼樣的影響呢?接下來我們就來分析這個問題.

5.1:創建process時的父子processcgroup關聯

process創建的時候,:do_fork()àcopy_process(),有如下代碼片段:

static struct task_struct *copy_process(unsigned long clone_flags,

                    unsigned long stack_start,

                    struct pt_regs *regs,

                    unsigned long stack_size,

                    int __user *child_tidptr,

                    struct pid *pid,

                    int trace)

{

    ……

    ……

    cgroup_fork(p);

    ……

    cgroup_fork_callbacks(p);

    ……

    cgroup_post_fork(p);

    ……

}

上面的代碼片段是創建新process的時候與cgroup關聯的函數.挨個分析如下:

void cgroup_fork(struct task_struct *child)

{

    task_lock(current);

    child->cgroups = current->cgroups;

    get_css_set(child->cgroups);

    task_unlock(current);

    INIT_LIST_HEAD(&child->cg_list);

}

如上面代碼所示,process和父process指向同一個cgroups.並且由於增加了一次引用.所以要調用get_css_set()來增加它的引用計數.最後初始化child->cg_list鏈表.

如代碼註釋上說的,這裡就有一個問題了:dup_task_struct()為子process創建struct task_struct的時候不是已經複製了父processcgroups?為什麼這裡還要對它進行一次賦值呢?這裡因為在dup_task_struct()中沒有持有保護鎖.而這裡又是一個競爭操作.因為在cgroup_attach_task()中可能會更改processcgroups指向.因此通過cgroup_attach_task()所得到的cgroups可能是一個無效的指向.在遞增其引用計數的時候就會因為它是一個無效的引用而發生錯誤.所以,這個函數在加鎖的情況下進行操作.確保了父子process之間的同步.

 

cgroup_fork_callbacks()代碼如下,

void cgroup_fork_callbacks(struct task_struct *child)

{

    if (need_forkexit_callback) {

        int i;

        for (i = 0; i < CGROUP_SUBSYS_COUNT; i++) {

            struct cgroup_subsys *ss = subsys[i];

            if (ss->fork)

                ss->fork(ss, child);

        }

    }

}

它主要是在process創建時調用subsys中的跟蹤函數:subsys->fork().

首先來跟蹤一下need_forkexita_callback這個變量.在如下代碼片段中:

static void __init cgroup_init_subsys(struct cgroup_subsys *ss)

{

    ……

    need_forkexit_callback |= ss->fork || ss->exit;

    ……

}

從這段代碼中我們可以看到,如果有subsys定義了forkexit函數,就會調need_forkexit_callback設置為1.

回到cgroup_fork_callback()這個函數中.我們發現.process會跟所有定義了forksubsys進行這次操作.就算process沒有在這個subsys,也會有這個操作.

 

Cgroup_pos_fork()如下所示:

void cgroup_post_fork(struct task_struct *child)

{

    if (use_task_css_set_links) {

        write_lock(&css_set_lock);

        if (list_empty(&child->cg_list))

            list_add(&child->cg_list, &child->cgroups->tasks);

        write_unlock(&css_set_lock);

    }

use_task_css_set_link1的情況下.就將子process鏈入到它所指向的css_set->task鏈表.

那什麼時候會將use_task_css_set_link設置為1?實際上,當你往cgroup中添加process的時候就會將其置1.

例如我們之前舉的一個例子中:

echo $$ > /dev/cgroup/eric_task/tasks

這個過程就會將use_task_css_set_link1.這個過程我們之後再來詳細分析.

 

5.2:process結束時的操作

process結束的時候,:

Do_exit() à cgroup_exit().

Cgroup_exit()代碼如下:

void cgroup_exit(struct task_struct *tsk, int run_callbacks)

{

    int i;

    struct css_set *cg;

 

    if (run_callbacks && need_forkexit_callback) {

        for (i = 0; i < CGROUP_SUBSYS_COUNT; i++) {

            struct cgroup_subsys *ss = subsys[i];

            if (ss->exit)

                ss->exit(ss, tsk);

        }

    }

 

    /*

     * Unlink from the css_set task list if necessary.

     * Optimistically check cg_list before taking

     * css_set_lock

     */

    if (!list_empty(&tsk->cg_list)) {

        write_lock(&css_set_lock);

        if (!list_empty(&tsk->cg_list))

            list_del(&tsk->cg_list);

        write_unlock(&css_set_lock);

    }

 

    /* Reassign the task to the init_css_set. */

    task_lock(tsk);

    cg = tsk->cgroups;

    tsk->cgroups = &init_css_set;

    task_unlock(tsk);

    if (cg)

        put_css_set_taskexit(cg);

}

這個函數的代碼邏輯比較清晰.首先,如果以1為調用參數(run_callbacks1),且有定義了exit操作的subsys.就調用這個subsysexit操作.

然後斷開task->cg_list鏈表.將其從所指向的css_set->task鏈上斷開.

最後,斷開當前的cgroup指向.將其指向init_css_set.也就是將其回覆到初始狀態.最後,減少舊指向css_set的引用計數.

 

在這個函數中,我們來跟蹤分析put_css_set_taskexit(),代碼如下:

static inline void put_css_set_taskexit(struct css_set *cg)

{

    __put_css_set(cg, 1);

}

 

跟蹤到__put_css_set():

static void __put_css_set(struct css_set *cg, int taskexit)

{

    int i;

    /*

     * Ensure that the refcount doesn't hit zero while any readers

     * can see it. Similar to atomic_dec_and_lock(), but for an

     * rwlock

     */

    if (atomic_add_unless(&cg->refcount, -1, 1))

        return;

    write_lock(&css_set_lock);

    if (!atomic_dec_and_test(&cg->refcount)) {

        write_unlock(&css_set_lock);

        return;

    }

    unlink_css_set(cg);

    write_unlock(&css_set_lock);

 

    rcu_read_lock();

    for (i = 0; i < CGROUP_SUBSYS_COUNT; i++) {

        struct cgroup *cgrp = cg->subsys[i]->cgroup;

        if (atomic_dec_and_test(&cgrp->count) &&

            notify_on_release(cgrp)) {

            if (taskexit)

                set_bit(CGRP_RELEASABLE, &cgrp->flags);

            check_for_release(cgrp);

        }

    }

    rcu_read_unlock();

    kfree(cg);

}

atomic_add_unless(v,a,u)表示如果v的值不為u就加a.返回1.如果v的值等於u就返回0

因此,這個函數首先減小css_set的引用計數.如果css_set的引用計數為1.就會將css_set釋放掉了. 要釋放css_set.首先要釋放css_set上掛載的鏈表.再釋放css_set結構本身所佔空間.

釋放css_set上的掛載鏈表是在unlink_css_set()中完成的.代碼如下:

static void unlink_css_set(struct css_set *cg)

{

    struct cg_cgroup_link *link;

    struct cg_cgroup_link *saved_link;

 

    hlist_del(&cg->hlist);

    css_set_count--;

 

    list_for_each_entry_safe(link, saved_link, &cg->cg_links,

                 cg_link_list) {

        list_del(&link->cg_link_list);

        list_del(&link->cgrp_link_list);

        kfree(link);

    }

}

它首先將cg->hlist斷開,也就是將其從css_set_table[ ]中刪除.然後減小css_set_count計數.最後遍歷刪除與css_set關聯的cg_cgroup_link.

另外,在這個函數中還涉及到了notify_on_release的操作.在後面再來詳細分析這一過程.這裡先把它放一下.

:cgroup文件系統的掛載

Cgroup文件系統定義如下:

static struct file_system_type cgroup_fs_type = {

    .name = "cgroup",

    .get_sb = cgroup_get_sb,

    .kill_sb = cgroup_kill_sb,

}

根據我們之前有關linux文件系統系列的文析.在掛載文件系統的時候,流程會流入file_system_type.get_sb().也就是cgroup_get_sb().由於該代碼較長.分段分析如下:

static int cgroup_get_sb(struct file_system_type *fs_type,

             int flags, const char *unused_dev_name,

             void *data, struct vfsmount *mnt)

{

    struct cgroup_sb_opts opts;

    int ret = 0;

    struct super_block *sb;

    struct cgroupfs_root *root;

    struct list_head tmp_cg_links;

 

    /* First find the desired set of subsystems */

    //解析掛載參數

    ret = parse_cgroupfs_options(data, &opts);

    if (ret) {

        if (opts.release_agent)

            kfree(opts.release_agent);

        return ret;

    }

在這一部份,解析掛載的參數,並將解析的結果存放到opts.opts-> subsys_bits表示指定關聯的subsys位圖,opts->flags:掛載的標誌: opts->release_agent表示指定的release_agent路徑.

 

    //分配並初始化cgroufs_root

    root = kzalloc(sizeof(*root), GFP_KERNEL);

    if (!root) {

        if (opts.release_agent)

            kfree(opts.release_agent);

        return -ENOMEM;

    }

 

    init_cgroup_root(root);

    /*root->subsys_bits: hierarchy上關聯的subsys*/

    root->subsys_bits = opts.subsys_bits;

    root->flags = opts.flags;

    /*如果帶了release_agent參數,將其copyroot0<release_agent_path*/

    if (opts.release_agent) {

        strcpy(root->release_agent_path, opts.release_agent);

        kfree(opts.release_agent);

    }

 

    /*初始化一個super block*/

    sb = sget(fs_type, cgroup_test_super, cgroup_set_super, root);

 

    /*如果發生錯誤*/

    if (IS_ERR(sb)) {

        kfree(root);

        return PTR_ERR(sb);

    }

在這一部份,主要分配並初始化了一個cgroupfs_root結構.裡面的子函數init_cgroup_root()我們在之前已經分析過,這裡不再贅述.其實的初始化包括:設置與之關聯的subsys位圖,掛載標誌和release_agent路徑.然後再調用sget()生成一個super_block結構.調用cgroup_test_super來判斷系統中是否有機同的cgroups_root.調用cgroup_set_super來對super_block進行初始化.

cgroup_set_super(),sb->s_fs_info 指向了cgroutfs_root,cgroufs_root.sb指向生成的super_block.

類似的.如果找到的super_block相關聯的cgroupfs_root所表示的subsys_bitsflags與當前cgroupfs_root相同的話,就表示是一個相同的super_block.因為它們的掛載參數是一樣的.

舉個例子來說明一下有重複super_block的情況:

[root@localhost ~]# mount -t cgroup cgroup -o debug /dev/cgroup/

[root@localhost ~]# mount -t cgroup cgroup -o debug /dev/eric_cgroup/

在上面的例子中,在掛載到/dev/eric_cgroup目錄的時候,就會找到一個相同的super_block.這樣實例上兩者的操作是一樣的.這兩個不同掛載點所代碼的vfsmount會找到同一個super_block.也就是說對其中一個目錄的操作都會同表現在另一個目錄中.

 

    /*重複掛載*/

    if (sb->s_fs_info != root) {

        /* Reusing an existing superblock */

        BUG_ON(sb->s_root == NULL);

        kfree(root);

        root = NULL;

    } else {

        /* New superblock */

        struct cgroup *cgrp = &root->top_cgroup;

        struct inode *inode;

        int i;

 

        BUG_ON(sb->s_root != NULL);

        /*初始化super_block對應的dentryinode*/

        ret = cgroup_get_rootdir(sb);

        if (ret)

            goto drop_new_super;

        inode = sb->s_root->d_inode;

 

        mutex_lock(&inode->i_mutex);

        mutex_lock(&cgroup_mutex);

 

        /*

         * We're accessing css_set_count without locking

         * css_set_lock here, but that's OK - it can only be

         * increased by someone holding cgroup_lock, and

         * that's us. The worst that can happen is that we

         * have some link structures left over

         */

         /*分配css_set_countcg_cgroup_link並將它們鏈入到tmp_cg_links*/

        ret = allocate_cg_links(css_set_count, &tmp_cg_links);

        if (ret) {

            mutex_unlock(&cgroup_mutex);

            mutex_unlock(&inode->i_mutex);

            goto drop_new_super;

        }

        /*bind subsys hierarchy*/

        ret = rebind_subsystems(root, root->subsys_bits);

        if (ret == -EBUSY) {

            mutex_unlock(&cgroup_mutex);

            mutex_unlock(&inode->i_mutex);

            goto drop_new_super;

        }

 

        /* EBUSY should be the only error here */

        BUG_ON(ret);

        /*root添加到roots鏈入.增加root_count計數*/

        list_add(&root->root_list, &roots);

        root_count++;

 

        /*將掛載根目錄dentry的私有結構d_fsdata反映向root->top_cgroup*/

        /*root->top_cgroup.dentry指向掛載的根目錄*/

        sb->s_root->d_fsdata = &root->top_cgroup;

        root->top_cgroup.dentry = sb->s_root;

 

        /* Link the top cgroup in this hierarchy into all

         * the css_set objects */

         /*將所有的css_set都和root->top_cgroup關聯起來*/

        write_lock(&css_set_lock);

        for (i = 0; i < CSS_SET_TABLE_SIZE; i++) {

            struct hlist_head *hhead = &css_set_table[i];

            struct hlist_node *node;

            struct css_set *cg;

 

            hlist_for_each_entry(cg, node, hhead, hlist) {

                struct cg_cgroup_link *link;

 

                BUG_ON(list_empty(&tmp_cg_links));

                link = list_entry(tmp_cg_links.next,

                          struct cg_cgroup_link,

                          cgrp_link_list);

                list_del(&link->cgrp_link_list);

                link->cg = cg;

                list_add(&link->cgrp_link_list,

                     &root->top_cgroup.css_sets);

                list_add(&link->cg_link_list, &cg->cg_links);

            }

        }

        write_unlock(&css_set_lock);

        /*釋放tmp_cg_links的多餘項*/

        free_cg_links(&tmp_cg_links);

 

        BUG_ON(!list_empty(&cgrp->sibling));

        BUG_ON(!list_empty(&cgrp->children));

        BUG_ON(root->number_of_cgroups != 1);

        /*root->top_cgroup下面創建一些文件,包括cgroup共有的和subsys私有的文件*/ 

        cgroup_populate_dir(cgrp);

        mutex_unlock(&inode->i_mutex);

        mutex_unlock(&cgroup_mutex);

    }

    /*vfsmountsuper_block關聯起來*/

    return simple_set_mnt(mnt, sb);

 

 drop_new_super:

    up_write(&sb->s_umount);

    deactivate_super(sb);

    free_cg_links(&tmp_cg_links);

    return ret;

}

這一部份,首先判斷找到的super_block是不是之前就存在的.如果是已經存在的,那就用不著再初始化一個cgroupfs_root結構了.將之前分配的結構釋放掉.然後調用simple_set_mnt()將取得的super_blockvfsmount相關聯後退出.

如果super_block是一個新建的.那麼就必須要繼續初始化cgroupfs_root.

首先,調用cgroup_get_rootdir()初始化super_block對應的dentryinode.

然後,調用rebind_subsystems()將需要關聯到hierarchysubsysroot->top_cgroup綁定起來.

最後,將所有的css_set都和root->top_cgroup關聯起來.這樣就可以從root->top_cgroup找到所有的process.再調用cgroup_populate_dir()在掛載目錄下創建一些文件,然後,調用simple_set_mnt()將取得的super_blockvfsmount相關聯後退出.

 

這個函數的流程還算簡單.下面來分析一下里面涉及到的重要的子函數:

6.1: parse_cgroupfs_options()函數分析

這個函數主要是對掛載的參數進行解析.函數代碼如下:

static int parse_cgroupfs_options(char *data,

                     struct cgroup_sb_opts *opts)

{

    /*如果掛載的時候沒有帶參數,o設為"all".表示將所有

      *subsys都與之關聯

      */

    char *token, *o = data ?: "all";

 

    opts->subsys_bits = 0;

    opts->flags = 0;

    opts->release_agent = NULL;

 

    /*各參數是以","分隔的*/

    while ((token = strsep(&o, ",")) != NULL) {

        if (!*token)

            return -EINVAL;

        /*如果為all.表示關聯所有的subsys*/

        if (!strcmp(token, "all")) {

            /* Add all non-disabled subsystems */

            int i;

            opts->subsys_bits = 0;

            for (i = 0; i < CGROUP_SUBSYS_COUNT; i++) {

                struct cgroup_subsys *ss = subsys[i];

                if (!ss->disabled)

                    opts->subsys_bits |= 1ul << i;

            }

        }

        /*如果指定參數noprefix.設定ROOT_NOPREFIX標誌*/

        /*在指定noprefix的情況下.subsys創建的文件不會帶subsys名稱的前綴*/

        else if (!strcmp(token, "noprefix")) {

            set_bit(ROOT_NOPREFIX, &opts->flags);

        }

        /*如果指定了release_agent.opt->release_agent分配內存,並將參數copy到裡面*/

        else if (!strncmp(token, "release_agent=", 14)) {

            /* Specifying two release agents is forbidden */

            if (opts->release_agent)

                return -EINVAL;

            opts->release_agent = kzalloc(PATH_MAX, GFP_KERNEL);

            if (!opts->release_agent)

                return -ENOMEM;

            strncpy(opts->release_agent, token + 14, PATH_MAX - 1);

            opts->release_agent[PATH_MAX - 1] = 0;

        }

         /*其它情況下,將所帶參數做為一個susys名處理.sussys[]找到

           *對應的subsys.然後將opts->subsys_bits中的位置1

           */

        else {

            struct cgroup_subsys *ss;

            int i;

            for (i = 0; i < CGROUP_SUBSYS_COUNT; i++) {

                ss = subsys[i];

                if (!strcmp(token, ss->name)) {

                    if (!ss->disabled)

                        set_bit(i, &opts->subsys_bits);

                    break;

                }

            }

            if (i == CGROUP_SUBSYS_COUNT)

                return -ENOENT;

        }

    }

 

    /* We can't have an empty hierarchy */

    /*如果沒有關聯到subsys.錯誤*/

    if (!opts->subsys_bits)

        return -EINVAL;

 

    return 0;

}

對照代碼中添加的註釋應該很容易看懂.這裡就不再做詳細分析了.

 

6.2: rebind_subsystems()函數分析

rebind_subsystems()用來將cgroupfs_rootsubsys綁定.代碼如下:

static int rebind_subsystems(struct cgroupfs_root *root,

                  unsigned long final_bits)

{

    unsigned long added_bits, removed_bits;

    struct cgroup *cgrp = &root->top_cgroup;

    int i;

 

    /*root->actual_subsys_bits表示當進root中所關鍵的subsys位圖*/

     /*如果在root->actual_subsys_bits.但沒有在final_bits.表示這是

    *一次remonut的操作.需要將舊的subsys移除.如果在final_bits

    *存在,但沒有在root->actual_subsys_bits,表示是需要添加的.

    */

    removed_bits = root->actual_subsys_bits & ~final_bits;

    added_bits = final_bits & ~root->actual_subsys_bits;

    /* Check that any added subsystems are currently free */

     /*如果要關聯的subsys已經在其它的hierarchy中了.失敗.

    *如果ss->root != &rootnode表示ss已經鏈入了其它的cgroupfs_root

    */

    for (i = 0; i < CGROUP_SUBSYS_COUNT; i++) {

        unsigned long bit = 1UL << i;

        struct cgroup_subsys *ss = subsys[i];

        if (!(bit & added_bits))

            continue;

        if (ss->root != &rootnode) {

            /* Subsystem isn't free */

            return -EBUSY;

        }

    }

 

    /* Currently we don't handle adding/removing subsystems when

     * any child cgroups exist. This is theoretically supportable

     * but involves complex error handling, so it's being left until

     * later */

     /*如果root->top_cgroup->children不為空.表示該hierarchy還要其它的cgroup

    *是不能被remount.(新掛載的root->top_cgroup在初始化的時候將children置空了)

    */

    if (!list_empty(&cgrp->children))

        return -EBUSY;

 

    /* Process each subsystem */

    for (i = 0; i < CGROUP_SUBSYS_COUNT; i++) {

        struct cgroup_subsys *ss = subsys[i];

        unsigned long bit = 1UL << i;

        /*添加subsys的情況*/

        if (bit & added_bits) {

            /* We're binding this subsystem to this hierarchy */

            /* 添加情況下.cgrp->subsys[i]指向dummytop->subsys[i]

              * 並更新dummytop->subsys[i]->root.將其指向要添加的root

              * 最後調用subsys->bind()操作

              */

            BUG_ON(cgrp->subsys[i]);

            BUG_ON(!dummytop->subsys[i]);

            BUG_ON(dummytop->subsys[i]->cgroup != dummytop);

            cgrp->subsys[i] = dummytop->subsys[i];

            cgrp->subsys[i]->cgroup = cgrp;

            list_add(&ss->sibling, &root->subsys_list);

            rcu_assign_pointer(ss->root, root);

            if (ss->bind)

                ss->bind(ss, cgrp);

 

        }

        /*移除subsys的情況*/

        else if (bit & removed_bits) {

            /* 移除操作,將對應的cgroup_subsys_state回歸到原來的樣子.並且也需要

              * 將與其subsys bind

              */

            /* We're removing this subsystem */

            BUG_ON(cgrp->subsys[i] != dummytop->subsys[i]);

            BUG_ON(cgrp->subsys[i]->cgroup != cgrp);

            if (ss->bind)

                ss->bind(ss, dummytop);

            dummytop->subsys[i]->cgroup = dummytop;

            cgrp->subsys[i] = NULL;

            rcu_assign_pointer(subsys[i]->root, &rootnode);

            list_del(&ss->sibling);

        } else if (bit & final_bits) {

            /* Subsystem state should already exist */

            BUG_ON(!cgrp->subsys[i]);

        } else {

            /* Subsystem state shouldn't exist */

            BUG_ON(cgrp->subsys[i]);

        }

    }

    /*更新root的位圖*/

    root->subsys_bits = root->actual_subsys_bits = final_bits;

    synchronize_rcu();

 

    return 0;

}

從這個函數也可以看出來.rootnode就是起一個參照的作用.用來判斷subsys是否處於初始化狀態.

 

6.3: cgroup_populate_dir()函數分析

cgroup_populate_dir()用來在掛載目錄下創建交互文件.代碼如下:

static int cgroup_populate_dir(struct cgroup *cgrp)

{

    int err;

    struct cgroup_subsys *ss;

 

    /* First clear out any existing files */

    /*先將cgrp所在的目錄清空*/

    cgroup_clear_directory(cgrp->dentry);

 

    /*創建files所代碼的幾個文件*/

    err = cgroup_add_files(cgrp, NULL, files, ARRAY_SIZE(files));

    if (err < 0)

        return err;

    /*如果是頂層top_cgroup.創建cft_release_agent所代碼的文件*/

    if (cgrp == cgrp->top_cgroup) {

        if ((err = cgroup_add_file(cgrp, NULL, &cft_release_agent)) < 0)

            return err;

    }

 

    /*對所有與cgrp->root關聯的subsys都調用populate()*/

    for_each_subsys(cgrp->root, ss) {

        if (ss->populate && (err = ss->populate(ss, cgrp)) < 0)

            return err;

    }

 

    return 0;

}

這個函數比較簡單.跟蹤cgroup_add_file().如下:

nt cgroup_add_file(struct cgroup *cgrp,

               struct cgroup_subsys *subsys,

               const struct cftype *cft)

{

    struct dentry *dir = cgrp->dentry;

    struct dentry *dentry;

    int error;

 

    char name[MAX_CGROUP_TYPE_NAMELEN + MAX_CFTYPE_NAME + 2] = { 0 };

    /*如果有指定subsys.且沒有使用ROOT_NOPREFIX標誌.需要在名稱前加上

     *subsys的名稱

     */

    if (subsys && !test_bit(ROOT_NOPREFIX, &cgrp->root->flags)) {

        strcpy(name, subsys->name);

        strcat(name, ".");

    }

    /*cft->name鏈接到name代表的字串後面*/

    strcat(name, cft->name);

    BUG_ON(!mutex_is_locked(&dir->d_inode->i_mutex));

    /*cgroup所在的目錄下尋找name所表示的dentry,如果不存在,則新建之*/

    dentry = lookup_one_len(name, dir, strlen(name));

    if (!IS_ERR(dentry)) {

        /*創建文件inode*/

        error = cgroup_create_file(dentry, 0644 | S_IFREG,

                        cgrp->root->sb);

        /*使dentry->d_fsdata指向文件所代表的cftype*/

        if (!error)

            dentry->d_fsdata = (void *)cft;

        dput(dentry);

    } else

        error = PTR_ERR(dentry);

    return error;

}

 

cgroup_create_file()函數代碼如下:

static int cgroup_create_file(struct dentry *dentry, int mode,

                struct super_block *sb)

{

    static struct dentry_operations cgroup_dops = {

        .d_iput = cgroup_diput,

    };

 

    struct inode *inode;

 

    if (!dentry)

        return -ENOENT;

    if (dentry->d_inode)

        return -EEXIST;

    /*分配一個inode*/

    inode = cgroup_new_inode(mode, sb);

    if (!inode)

        return -ENOMEM;

    /*如果新建的是目錄*/

    if (S_ISDIR(mode)) {

        inode->i_op = &cgroup_dir_inode_operations;

        inode->i_fop = &simple_dir_operations;

 

        /* start off with i_nlink == 2 (for "." entry) */

        inc_nlink(inode);

 

        /* start with the directory inode held, so that we can

         * populate it without racing with another mkdir */

        mutex_lock_nested(&inode->i_mutex, I_MUTEX_CHILD);

    }

    /*新建一般文件*/

    else if (S_ISREG(mode)) {

        inode->i_size = 0;

        inode->i_fop = &cgroup_file_operations;

    }

    dentry->d_op = &cgroup_dops;

    /*dentryinode關聯起來*/

    d_instantiate(dentry, inode);

    dget(dentry);   /* Extra count - pin the dentry in core */

    return 0;

}

從這個函數我們可以看到.如果是目錄的話,對應的操作集為simple_dir_operationscgroup_dir_inode_operations.它與cgroup_get_rootdir()中對根目錄對應的inode所設置的操作集是一樣的.如果是一般文件,它的操作集為cgroup_file_operations.

在這裡,先將cgroup中的文件操作放到一邊,我們在之後再來詳細分析這個過程.

現在.我們已經將cgroup文件系統的掛載分析完成.接下來看它下面子層cgroup的創建.

 

:創建子層cgroup

在目錄下通過mkdir調用就可以創建一個子層cgroup.下面就分析這一過程:

經過上面的分析可以得知,cgroup中目錄的操作集為: cgroup_dir_inode_operations.結構如下:

static struct inode_operations cgroup_dir_inode_operations = {

    .lookup = simple_lookup,

    .mkdir = cgroup_mkdir,

    .rmdir = cgroup_rmdir,

    .rename = cgroup_rename,

};

從上面看到,對應mkdir的入口為cgroup_mkdir().代碼如下:

static int cgroup_mkdir(struct inode *dir, struct dentry *dentry, int mode)

{

    /*找到它的上一級cgroup*/

    struct cgroup *c_parent = dentry->d_parent->d_fsdata;

 

    /* the vfs holds inode->i_mutex already */

    /*調用cgroup_create創建cgroup*/

    return cgroup_create(c_parent, dentry, mode | S_IFDIR);

}

跟蹤cgroup_create().代碼如下:

static long cgroup_create(struct cgroup *parent, struct dentry *dentry,

                 int mode)

{

    struct cgroup *cgrp;

    struct cgroupfs_root *root = parent->root;

    int err = 0;

    struct cgroup_subsys *ss;

    struct super_block *sb = root->sb;

    /*分配並初始化一個cgroup*/

    cgrp = kzalloc(sizeof(*cgrp), GFP_KERNEL);

    if (!cgrp)

        return -ENOMEM;

 

    /* Grab a reference on the superblock so the hierarchy doesn't

     * get deleted on unmount if there are child cgroups.  This

     * can be done outside cgroup_mutex, since the sb can't

     * disappear while someone has an open control file on the

     * fs */

    atomic_inc(&sb->s_active);

 

    mutex_lock(&cgroup_mutex);

 

    init_cgroup_housekeeping(cgrp);

 

    /*設置cgrp的層次關係*/

    cgrp->parent = parent;

    cgrp->root = parent->root;

    cgrp->top_cgroup = parent->top_cgroup;

 

    /*如果上一級cgroup設置了CGRP_NOTIFY_ON_RELEASE.cgrp也設置這個標誌*/

    if (notify_on_release(parent))

        set_bit(CGRP_NOTIFY_ON_RELEASE, &cgrp->flags);

 

    /*調用subsys_create()生成cgroup_subsys_state.並與cgrp相關聯*/

    for_each_subsys(root, ss) {

        struct cgroup_subsys_state *css = ss->create(ss, cgrp);

        if (IS_ERR(css)) {

            err = PTR_ERR(css);

            goto err_destroy;

        }

        init_cgroup_css(css, ss, cgrp);

    }

 

    /*cgrp添加到上一層cgroupchildren鏈表*/

    list_add(&cgrp->sibling, &cgrp->parent->children);

    /*增加rootcgroups數目計數*/

    root->number_of_cgroups++;

    /*在當前目錄生成一個目錄*/

    err = cgroup_create_dir(cgrp, dentry, mode);

    if (err < 0)

        goto err_remove;

 

    /* The cgroup directory was pre-locked for us */

    BUG_ON(!mutex_is_locked(&cgrp->dentry->d_inode->i_mutex));

    /*cgrp下創建幾個交互文件*/

    err = cgroup_populate_dir(cgrp);

    /* If err < 0, we have a half-filled directory - oh well ;) */

 

    mutex_unlock(&cgroup_mutex);

    mutex_unlock(&cgrp->dentry->d_inode->i_mutex);

 

    return 0;

 

 err_remove:

 

    list_del(&cgrp->sibling);

    root->number_of_cgroups--;

 

 err_destroy:

 

    for_each_subsys(root, ss) {

        if (cgrp->subsys[ss->subsys_id])

            ss->destroy(ss, cgrp);

    }

 

    mutex_unlock(&cgroup_mutex);

 

    /* Release the reference count that we took on the superblock */

    deactivate_super(sb);

 

    kfree(cgrp);

    return err;

}

在這個函數中,主要分配並初始化了一個cgroup結構.並且將它和它的上一層目錄以及整個cgroupfs_root構成一個空間層次關係.然後,再調用subsys>create()操作函數.來讓subsys知道已經創建了一個cgroup結構.

為了理順這一部份.將前面分析的cgroup文件系統掛載和cgroup的創建.以及接下來要分析的attach_task()操作總結成一個圖.如下示:

 

:cgroup中文件的操作

接下來,就來看cgroup文件的操作.在上面曾分析到:文件對應的操作集為cgroup_file_operations.如下所示:

static struct file_operations cgroup_file_operations = {

    .read = cgroup_file_read,

    .write = cgroup_file_write,

    .llseek = generic_file_llseek,

    .open = cgroup_file_open,

    .release = cgroup_file_release,

}

 

7.1:cgrou文件的open操作

對應的函數為cgroup_file_open().代碼如下:

static int cgroup_file_open(struct inode *inode, struct file *file)

{

    int err;

    struct cftype *cft;

 

    err = generic_file_open(inode, file);

    if (err)

        return err;

 

    /*取得文件對應的struct cftype*/

    cft = __d_cft(file->f_dentry);

    if (!cft)

        return -ENODEV;

    /*如果定義了read_map或者是read_seq_string*/

    if (cft->read_map || cft->read_seq_string) {

        struct cgroup_seqfile_state *state =

            kzalloc(sizeof(*state), GFP_USER);

        if (!state)

            return -ENOMEM;

        state->cft = cft;

        state->cgroup = __d_cgrp(file->f_dentry->d_parent);

        file->f_op = &cgroup_seqfile_operations;

        err = single_open(file, cgroup_seqfile_show, state);

        if (err < 0)

            kfree(state);

    }

    /*否則調用cft->open()*/

    else if (cft->open)

        err = cft->open(inode, file);

    else

        err = 0;

 

    return err;

}

有兩種情況.一種是定義了read_map或者是read_seq_string的情況.這種情況下,它對應的操作集為cgroup_seqfile_operations.如果是其它的情況.調用cftypeopen()函數.第一種情況,我們等以後遇到了這樣的情況再來詳細分析.

 

7.2:cgroup文件的read操作

對應函數為cgroup_file_read().代碼如下:

static ssize_t cgroup_file_read(struct file *file, char __user *buf,

                   size_t nbytes, loff_t *ppos)

{

    struct cftype *cft = __d_cft(file->f_dentry);

    struct cgroup *cgrp = __d_cgrp(file->f_dentry->d_parent);

 

    if (!cft || cgroup_is_removed(cgrp))

        return -ENODEV;

 

    if (cft->read)

        return cft->read(cgrp, cft, file, buf, nbytes, ppos);

    if (cft->read_u64)

        return cgroup_read_u64(cgrp, cft, file, buf, nbytes, ppos);

    if (cft->read_s64)

        return cgroup_read_s64(cgrp, cft, file, buf, nbytes, ppos);

    return -EINVAL;

}

如上代碼所示.read操作會轉入到cftyperead()或者read_u64或者read_s64的函數中.

 

7.3:cgroup文件的wirte操作

對應的操作函數是cgroup_file_write().如下示:

static ssize_t cgroup_file_write(struct file *file, const char __user *buf,

                        size_t nbytes, loff_t *ppos)

{

    struct cftype *cft = __d_cft(file->f_dentry);

    struct cgroup *cgrp = __d_cgrp(file->f_dentry->d_parent);

 

    if (!cft || cgroup_is_removed(cgrp))

        return -ENODEV;

    if (cft->write)

        return cft->write(cgrp, cft, file, buf, nbytes, ppos);

    if (cft->write_u64 || cft->write_s64)

        return cgroup_write_X64(cgrp, cft, file, buf, nbytes, ppos);

    if (cft->write_string)

        return cgroup_write_string(cgrp, cft, file, buf, nbytes, ppos);

    if (cft->trigger) {

        int ret = cft->trigger(cgrp, (unsigned int)cft->private);

        return ret ? ret : nbytes;

    }

    return -EINVAL;

}

從上面可以看到.最終的操作會轉入到cftypewrite或者wirte_u64或者wirte_string或者trigger函數中.

 

7.4:debug subsytem分析

debug subsystem為例來說明cgroup中的文件操作

Debug subsys定義如下:

struct cgroup_subsys debug_subsys = {

    .name = "debug",

    .create = debug_create,

    .destroy = debug_destroy,

    .populate = debug_populate,

    .subsys_id = debug_subsys_id,

}

cgroup_init_subsys(),會以dummytop為參數調用debug.create().對應函數為debug_create().代碼如下:

static struct cgroup_subsys_state *debug_create(struct cgroup_subsys *ss,

                           struct cgroup *cont)

{

    struct cgroup_subsys_state *css = kzalloc(sizeof(*css), GFP_KERNEL);

 

    if (!css)

        return ERR_PTR(-ENOMEM);

 

    return css;

}

這裡沒啥好說的,就是分配了一個cgroup_subsys_state結構.

 

然後,cgroup掛載.指令如下:

[root@localhost ~]# mount -t cgroup cgroup -o debug /dev/cgroup/

rebind_subsystems(),會調用subsysbind函數.但在debug中無此接口.故不需要考慮.

然後在cgroup_populate_dir()中會調用populate接口.對應函數為debug_populate().代碼如下:

static int debug_populate(struct cgroup_subsys *ss, struct cgroup *cont)

{

    return cgroup_add_files(cont, ss, files, ARRAY_SIZE(files));

}

Debug中的files定義如下:

static struct cftype files[] =  {

    {

        .name = "cgroup_refcount",

        .read_u64 = cgroup_refcount_read,

    },

    {

        .name = "taskcount",

        .read_u64 = taskcount_read,

    },

 

    {

        .name = "current_css_set",

        .read_u64 = current_css_set_read,

    },

 

    {

        .name = "current_css_set_refcount",

        .read_u64 = current_css_set_refcount_read,

    },

 

    {

        .name = "releasable",

        .read_u64 = releasable_read,

    },

}

來觀察一下 /dev/cgroup下的文件:

[root@localhost ~]# tree /dev/cgroup/

/dev/cgroup/

|-- debug.cgroup_refcount

|-- debug.current_css_set

|-- debug.current_css_set_refcount

|-- debug.releasable

|-- debug.taskcount

|-- notify_on_release

|-- release_agent

`-- tasks

 

0 directories, 8 files

上面帶debug字樣的文件是從debug subsys中創建的.其它的是cgroup.cfiles中創建的.

我們先來分析每一個subsys共有的文件.tasks,release_agentnotify_on_release.

 

7.5:task文件操作

Tasks文件對應的cftype結構如下:

static struct cftype files[] = {

    {

        .name = "tasks",

        .open = cgroup_tasks_open,

        .write_u64 = cgroup_tasks_write,

        .release = cgroup_tasks_release,

        .private = FILE_TASKLIST,

    }

 

7.5.1:task文件的open操作

當打開文件時,流程就會轉入cgroup_tasks_open().代碼如下:

static int cgroup_tasks_open(struct inode *unused, struct file *file)

{

    /*取得該文件所在層次的cgroup*/

    struct cgroup *cgrp = __d_cgrp(file->f_dentry->d_parent);

    pid_t *pidarray;

    int npids;

    int retval;

 

    /* Nothing to do for write-only files */

    /*如果是只寫的文件系統*/

    if (!(file->f_mode & FMODE_READ))

        return 0;

 

    /*

     * If cgroup gets more users after we read count, we won't have

     * enough space - tough.  This race is indistinguishable to the

     * caller from the case that the additional cgroup users didn't

     * show up until sometime later on.

     */

     /*得到該層cgroup所關聯的process個數*/

    npids = cgroup_task_count(cgrp);

    /*npidsprocesspid存放分配空間*/

    pidarray = kmalloc(npids * sizeof(pid_t), GFP_KERNEL);

    if (!pidarray)

        return -ENOMEM;

    /* 將與cgroup關聯processpid存放到pid_array_load數組.

      * 並且按照從小到大的順序排列

     */

    npids = pid_array_load(pidarray, npids, cgrp);

    sort(pidarray, npids, sizeof(pid_t), cmppid, NULL);

 

    /*

     * Store the array in the cgroup, freeing the old

     * array if necessary

     */

     /* npids,pidarray信息存放到cgroup.如果cgroup之前

       * 就有task_pids.將其佔放的空間釋放

       */

    down_write(&cgrp->pids_mutex);

    kfree(cgrp->tasks_pids);

    cgrp->tasks_pids = pidarray;

    cgrp->pids_length = npids;

    cgrp->pids_use_count++;

    up_write(&cgrp->pids_mutex);

 

    /*將文件對應的操作集更改為cgroup_task_operations*/

    file->f_op = &cgroup_tasks_operations;

 

    retval = seq_open(file, &cgroup_tasks_seq_operations);

    /*如果操作失敗,cgroup中的pid信息釋放*/

    if (retval) {

        release_cgroup_pid_array(cgrp);

        return retval;

    }

    ((struct seq_file *)file->private_data)->private = cgrp;

    return 0;

}

首先,我們來思考一下這個問題:怎麼得到與cgroup關聯的process?

回到在上面列出來的資料結構關係圖.每個process都會指向一個css_set.而與這個css_set關聯的所有process都會鏈入到css_set->tasks鏈表.cgroup又可能通過一個中間結構cg_cgroup_link來尋找所有與之關聯的所有css_set.從而可以得到與cgroup關聯的所有process.

在上面的代碼中,通過調用cgroup_task_count()來得到與之關聯的process數目,代碼如下:

int cgroup_task_count(const struct cgroup *cgrp)

{

    int count = 0;

    struct cg_cgroup_link *link;

 

    read_lock(&css_set_lock);

    list_for_each_entry(link, &cgrp->css_sets, cgrp_link_list) {

        count += atomic_read(&link->cg->refcount);

    }

    read_unlock(&css_set_lock);

    return count;

}

它就是遍歷cgro->css_sets.並調其轉換為cg_cgroup_link.再從這個link得到css_set.這個css_set的引用計數就是與這個指向這個css_settask數目.

 

在代碼中,是通過pid_array_load()來得到與cgroup關聯的task,並且將processpid寫入數組pidarray.代碼如下:

static int pid_array_load(pid_t *pidarray, int npids, struct cgroup *cgrp)

{

    int n = 0;

    struct cgroup_iter it;

    struct task_struct *tsk;

    cgroup_iter_start(cgrp, &it);

    while ((tsk = cgroup_iter_next(cgrp, &it))) {

        if (unlikely(n == npids))

            break;

        pidarray[n++] = task_pid_vnr(tsk);

    }

    cgroup_iter_end(cgrp, &it);

    return n;

}

我們在這裡遇到了一個新的結構:struct cgroup_iter.它是cgroup的一個迭代器,通過它可以遍歷取得與cgroup關聯的task.它的使用方法為:

1:調用cgroup_iter_start()來初始化這個迭代碼.

2:調用cgroup_iter_next()用來取得cgroup中的下一個task

3:使用完了,調用cgroup_iner_end().

下面來分析這三個過程:

Cgroup_iter_start()代碼如下:

void cgroup_iter_start(struct cgroup *cgrp, struct cgroup_iter *it)

{

    /*

     * The first time anyone tries to iterate across a cgroup,

     * we need to enable the list linking each css_set to its

     * tasks, and fix up all existing tasks.

     */

    if (!use_task_css_set_links)

        cgroup_enable_task_cg_lists();

 

    read_lock(&css_set_lock);

    it->cg_link = &cgrp->css_sets;

    cgroup_advance_iter(cgrp, it);

}

我們在這裡再次遇到了use_task_css_set_links變量.在之前分析cgroup_post_fork()中的時候,我們曾說過,只有在use_task_css_set_link設置為1的時候,才會調task->cg_list鏈入到css_set->tasks.

所以,在這個地方,如果use_task_css_set_link0.那就必須要將之前所有的process都鏈入到它所指向的css_set->tasks鏈表.這個過程是在cgroup_enable_task_cg_lists()完成的,這個函數相當簡單,就是一個task的遍歷,然後就是鏈表的鏈入,在這裡就不再詳細分析了.請自行閱讀它的代碼.*^_^*

然後,it->cg_link指向cgrp->css_sets.我們在前面說過,可以通過cgrp->css_sets就可以得得所有的與cgroup關聯的css_set.

到這裡,這個迭代器裡面還是空的,接下來往裡面填充資料.這個過程是在cgroup_advance_iter()中完成,代碼如下示:

static void cgroup_advance_iter(struct cgroup *cgrp,

                  struct cgroup_iter *it)

{

struct list_head *l = it->cg_link;

struct cg_cgroup_link *link;

struct css_set *cg;

 

/* Advance to the next non-empty css_set */

do {

    l = l->next;

    if (l == &cgrp->css_sets) {

        it->cg_link = NULL;

        return;

    }

   link = list_entry(l, struct cg_cgroup_link, cgrp_link_list);

    cg = link->cg;

} while (list_empty(&cg->tasks));

it->cg_link = l;

it->task = cg->tasks.next;

}

通過前面的分析可得知,可通過it->cg_link找到與之關聯的css_set,然後再通過css_set找到與它關聯的task鏈表.因此每次往cgroup迭代器裡填充資料,就是找到一個tasks鏈表不為空的css_set.取資料就從css_set->tasks中取.如果資料取完了,就找下一個tasks鏈表不為空的css_set.

這樣,這個函數的代碼就很簡單了.它就是找到it->cg_linktasks鏈表不為空的css_set.

 

cgroup_iter_next()的代碼如下:

struct task_struct *cgroup_iter_next(struct cgroup *cgrp,

                    struct cgroup_iter *it)

{

    struct task_struct *res;

    struct list_head *l = it->task;

 

    /* If the iterator cg is NULL, we have no tasks */

    if (!it->cg_link)

        return NULL;

    res = list_entry(l, struct task_struct, cg_list);

    /* Advance iterator to find next entry */

    l = l->next;

    if (l == &res->cgroups->tasks) {

        /* We reached the end of this task list - move on to

         * the next cg_cgroup_link */

        cgroup_advance_iter(cgrp, it);

    } else {

        it->task = l;

    }

    return res;

}

如果it->cg_link為空表示it->cg_link已經遍歷完了,也就不存放在task.否則,it->task中取得task.如果已經是最後一個task就必須要調用cgroup_advance_iter()填充迭代器裡面的資料.最後將取得的task返回.

 

cgroup_iter_end()用來對迭代碼進行收尾的工作,代碼如下:

void cgroup_iter_end(struct cgroup *cgrp, struct cgroup_iter *it)

{

    read_unlock(&css_set_lock);

}

它就是釋放了在cgroup_iter_start()中持有的鎖.

 

回到cgroup_tasks_open().我們接下來會遇到kernelsequential file提供的一組接口.首先在代碼遇到的是seq_open().代碼如下:

int seq_open(struct file *file, const struct seq_operations *op)

{

    struct seq_file *p = file->private_data;

 

    if (!p) {

        p = kmalloc(sizeof(*p), GFP_KERNEL);

        if (!p)

            return -ENOMEM;

        file->private_data = p;

    }

    memset(p, 0, sizeof(*p));

    mutex_init(&p->lock);

    p->op = op;

    file->f_version = 0;

    /* SEQ files support lseek, but not pread/pwrite */

    file->f_mode &= ~(FMODE_PREAD | FMODE_PWRITE);

    return 0;

}

從代碼中可以看出,它就是初始化了一個struct seq_file結構.並且將其關聯到file->private_data.在這裡要注意將seq_file->op設置成了參數op.在我們分析的這個情景中,也就是cgroup_tasks_seq_operations.這個在我們分析文件的讀操作的時候會用到的.

 

7.5.2:task文件的read操作

從上面的代碼中可看到.open的時候,更改了file->f_op.將其指向了cgroup_tasks_operations.該結構如下:

static struct file_operations cgroup_tasks_operations = {

    .read = seq_read,

    .llseek = seq_lseek,

    .write = cgroup_file_write,

    .release = cgroup_tasks_release,

}

相應的,read操作就會轉入到seq_read().由於該函數篇幅較大,這裡就不列出了.感興趣的可以自己跟蹤看一下,其它就是循環調用seq_file->op->start() à seq_file->op->show() à seq_file->op->next() à seq_file->op->stop()的過程.

我們在上面分析task文件的open操作的時候,曾經提配過,seq_file->op被指向了cgroup_tasks_seq_operations.定義如下:

static struct seq_operations cgroup_tasks_seq_operations = {

    .start = cgroup_tasks_start,

    .stop = cgroup_tasks_stop,

    .next = cgroup_tasks_next,

    .show = cgroup_tasks_show,

}

Cgroup_tasks_start()代碼如下:

static void *cgroup_tasks_start(struct seq_file *s, loff_t *pos)

{

    /*

     * Initially we receive a position value that corresponds to

     * one more than the last pid shown (or 0 on the first call or

     * after a seek to the start). Use a binary-search to find the

     * next pid to display, if any

     */

    struct cgroup *cgrp = s->private;

    int index = 0, pid = *pos;

    int *iter;

 

    down_read(&cgrp->pids_mutex);

    if (pid) {

        int end = cgrp->pids_length;

 

        while (index < end) {

            int mid = (index + end) / 2;

            if (cgrp->tasks_pids[mid] == pid) {

                index = mid;

                break;

            } else if (cgrp->tasks_pids[mid] <= pid)

                index = mid + 1;

            else

                end = mid;

        }

    }

    /* If we're off the end of the array, we're done */

    if (index >= cgrp->pids_length)

        return NULL;

    /* Update the abstract position to be the actual pid that we found */

    iter = cgrp->tasks_pids + index;

    *pos = *iter;

    return iter;

}

它以二分法從cgrp->tasks_pids[ ]中去尋找第一個大於或者等於參數*pos值的項.如果找到了,返回該項.如果沒找到.返回NULL.

 

cgroup_tasks_show()代碼如下:

static int cgroup_tasks_show(struct seq_file *s, void *v)

{

    return seq_printf(s, "%d\n", *(int *)v);

}

它就是將pid轉換為了字符串.

 

cgroup_tasks_next()就是找到數組中的下一項.代碼如下:

static void *cgroup_tasks_next(struct seq_file *s, void *v, loff_t *pos)

{

    struct cgroup *cgrp = s->private;

    int *p = v;

    int *end = cgrp->tasks_pids + cgrp->pids_length;

 

    /*

     * Advance to the next pid in the array. If this goes off the

     * end, we're done

     */

    p++;

    if (p >= end) {

        return NULL;

    } else {

        *pos = *p;

        return p;

    }

}

 

cgroup_tasks_stop()代碼如下:

static void cgroup_tasks_stop(struct seq_file *s, void *v)

{

    struct cgroup *cgrp = s->private;

    up_read(&cgrp->pids_mutex);

}

它只是釋放了在cgroup_tasks_start()中持有的讀寫鎖.

 

7.5.3:task文件的close操作

Task文件close,調用的相應接口為cgroup_tasks_release().代碼如下:

static int cgroup_tasks_release(struct inode *inode, struct file *file)

{

    struct cgroup *cgrp = __d_cgrp(file->f_dentry->d_parent);

 

    if (!(file->f_mode & FMODE_READ))

        return 0;

 

    release_cgroup_pid_array(cgrp);

    return seq_release(inode, file);

}

它就是將cgroup中的pid信息與seqfile信息釋放掉.

 

到這裡,我們已經分析完了task文件的open,read,close操作.我們現在就可以實現一下,看上面的分析是否正確.

在前面已經分析中cgroupfs_root.top_cgroup會將系統中的所有css_set與之關聯起來,那麼通過cgroupfs_root_top_cgroup找到的process應該是系統當前的所有process.那麼相應的,在掛載目錄的task文件的內容.應該是系統中所有processpid.

如下所示:

[root@localhost cgroup]# cat tasks

1

2

3

………

………

2578

其實,這樣做是cgroup子系統開發者特意設置的.它表示所有的process都在hierarchy的控制之下.

反過來,當我們在掛載目錄mkdir一個目錄,它下面的task文件內容應該是空的.因為在mkdir,它對應的cgroup並沒有關聯任何task.

如下所示:

[root@localhost cgroup]# mkdir eric

[root@localhost cgroup]# cat eric/tasks

[root@localhost cgroup]#

下面我們來看一下task文件的寫操作,也就是怎樣將process添加進cgroup.

 

7.5.4:task文件的write操作

根據上面的文件,可得知task文件的write操作對應的函數為int cgroup_tasks_write().代碼如下:

static int cgroup_tasks_write(struct cgroup *cgrp, struct cftype *cft, u64 pid)

{

    int ret;

    /*如果cgroup已經被移除了,非法*/

    if (!cgroup_lock_live_group(cgrp))

        return -ENODEV;

    /*PIDpidprocesscgroup關聯*/

    ret = attach_task_by_pid(cgrp, pid);

    cgroup_unlock();

    return ret;

}

Attach_task_by_pid()的代碼如下:

static int attach_task_by_pid(struct cgroup *cgrp, u64 pid)

{

    struct task_struct *tsk;

    int ret;

 

    /*如果pid不為0.尋找PIDpidtask.並增加其引用計數*/

    if (pid) {

        rcu_read_lock();

        tsk = find_task_by_vpid(pid);

        if (!tsk || tsk->flags & PF_EXITING) {

            rcu_read_unlock();

            return -ESRCH;

        }

        get_task_struct(tsk);

        rcu_read_unlock();

 

        if ((current->euid) && (current->euid != tsk->uid)

            && (current->euid != tsk->suid)) {

            put_task_struct(tsk);

            return -EACCES;

        }

    }

    /*如果pid0.表示是將當前process添加進cgroup*/

    else {

        tsk = current;

        get_task_struct(tsk);

    }

    /*cgrouptask相關聯*/

    ret = cgroup_attach_task(cgrp, tsk);

    /*操作完成,減少其引用計數*/

    put_task_struct(tsk);

    return ret;

}

如果寫入的是一個不這0的數,表示的是processPID.如果是寫入0,表示是將當前process.這個操作的核心操作是cgroup_attach_task().代碼如下:

int cgroup_attach_task(struct cgroup *cgrp, struct task_struct *tsk)

{

    int retval = 0;

    struct cgroup_subsys *ss;

    struct cgroup *oldcgrp;

    struct css_set *cg = tsk->cgroups;

    struct css_set *newcg;

    struct cgroupfs_root *root = cgrp->root;

    int subsys_id;

 

    /*得到與cgroup關聯的第一個subsys的序號*/

    get_first_subsys(cgrp, NULL, &subsys_id);

 

    /* Nothing to do if the task is already in that cgroup */

    /*找到這個process之前所屬的cgroup*/

    oldcgrp = task_cgroup(tsk, subsys_id);

    /*如果已經在這個cgrp裡面了.*/

    if (cgrp == oldcgrp)

        return 0;

   

    /* 遍歷與hierarchy關聯的subsys

      * 如果subsys定義了can_attach函數,就調用它

      */

    for_each_subsys(root, ss) {

        if (ss->can_attach) {

            retval = ss->can_attach(ss, cgrp, tsk);

            if (retval)

                return retval;

        }

    }

 

    /*

     * Locate or allocate a new css_set for this task,

     * based on its final set of cgroups

     */

     /*找到這個task所關聯的css_set.如果不存在,則新建一個*/

    newcg = find_css_set(cg, cgrp);

    if (!newcg)

        return -ENOMEM;

 

    task_lock(tsk);

   

    /*如果task正在執行exit操作*/

    if (tsk->flags & PF_EXITING) {

        task_unlock(tsk);

        put_css_set(newcg);

        return -ESRCH;

    }

    /*tak->cgroup指向這個css_set*/

    rcu_assign_pointer(tsk->cgroups, newcg);

    task_unlock(tsk);

 

    /* Update the css_set linked lists if we're using them */

    /*更改task->cg_list*/

    write_lock(&css_set_lock);

    if (!list_empty(&tsk->cg_list)) {

        list_del(&tsk->cg_list);

        list_add(&tsk->cg_list, &newcg->tasks);

    }

    write_unlock(&css_set_lock);

 

    /* 遍歷與hierarchy關聯的subsys

      * 如果subsys定義了attach 函數,就調用它

      */

    for_each_subsys(root, ss) {

        if (ss->attach)

            ss->attach(ss, cgrp, oldcgrp, tsk);

    }

    set_bit(CGRP_RELEASABLE, &oldcgrp->flags);

    synchronize_rcu();

    /*減小舊指向的引用計數*/

put_css_set(cg);

    return 0;

}

這個函數邏輯很清楚,它就是初始化task->cgroup.然後將它和subsys相關聯.可自行參照代碼中的註釋進行分析.這裡就不再贅述了.

在這裡,詳細分析一下find_css_set()函數,這個函數有點意思.代碼如下:

static struct css_set *find_css_set(

    struct css_set *oldcg, struct cgroup *cgrp)

{

    struct css_set *res;

    struct cgroup_subsys_state *template[CGROUP_SUBSYS_COUNT];

    int i;

 

    struct list_head tmp_cg_links;

    struct cg_cgroup_link *link;

 

    struct hlist_head *hhead;

 

    /* First see if we already have a cgroup group that matches

     * the desired set */

    read_lock(&css_set_lock);

    /*尋找從oldcg轉換為cgrpcss_set.如果不存在,返回NULL */

    res = find_existing_css_set(oldcg, cgrp, template);

    /*如果css_set已經存在,增加其引用計數後退出*/

    if (res)

        get_css_set(res);

    read_unlock(&css_set_lock);

 

    if (res)

        return res;

這一部份,先從哈希數組中搜索從oldcg轉換cgrpcss_set.如果不存在,返回NULL.如果在哈希數組中存放,增加其引用計數返回即可.

Find_existing_css_set()的代碼如下:

static struct css_set *find_existing_css_set(

    struct css_set *oldcg,

    struct cgroup *cgrp,

    struct cgroup_subsys_state *template[])

{

    int i;

    struct cgroupfs_root *root = cgrp->root;

    struct hlist_head *hhead;

    struct hlist_node *node;

    struct css_set *cg;

 

    /* Built the set of subsystem state objects that we want to

     * see in the new css_set */

    for (i = 0; i < CGROUP_SUBSYS_COUNT; i++) {

        if (root->subsys_bits & (1UL << i)) {

            /* Subsystem is in this hierarchy. So we want

             * the subsystem state from the new

             * cgroup */

            template[i] = cgrp->subsys[i];

        } else {

            /* Subsystem is not in this hierarchy, so we

             * don't want to change the subsystem state */

            template[i] = oldcg->subsys[i];

        }

    }

 

    hhead = css_set_hash(template);

    hlist_for_each_entry(cg, node, hhead, hlist) {

        if (!memcmp(template, cg->subsys, sizeof(cg->subsys))) {

            /* All subsystems matched */

            return cg;

        }

    }

 

    /* No existing cgroup group matched */

    return NULL;

}

如果subsys與新的cgroup相關聯,那麼它指向新的cgroup->subsys[]中的對應項.否則指向舊的cgrop的對應項.這樣做主要是因為,process可能還被關聯在其它的hierarchy.所以要保持它在其它hierarchy中的信息.

最後,css_set_table[ ]中尋找看是否有與template相等的項.有的話返回該項.如果沒有.返回NULL.

 

    /*分配一個css_set*/

    res = kmalloc(sizeof(*res), GFP_KERNEL);

    if (!res)

        return NULL;

 

    /* Allocate all the cg_cgroup_link objects that we'll need */

    /*分配root_countcg_cgroup_link*/

    if (allocate_cg_links(root_count, &tmp_cg_links) < 0) {

        kfree(res);

        return NULL;

    }

 

    /* 初始化剛分配的css_set */

    atomic_set(&res->refcount, 1);

    INIT_LIST_HEAD(&res->cg_links);

    INIT_LIST_HEAD(&res->tasks);

    INIT_HLIST_NODE(&res->hlist);

 

    /* Copy the set of subsystem state objects generated in

     * find_existing_css_set() */

     /*設置css_set->subsys*/

    memcpy(res->subsys, template, sizeof(res->subsys));

運行到這裡的話.表示沒有從css_set_table[ ]中找到相應項.因此需要分配並初始化一個css_set結構.並且設置css_setsubsys.

 

    write_lock(&css_set_lock);

    /* Add reference counts and links from the new css_set. */

    /*遍歷所有的subsys以及css_set 中的subsys[ ].

     *建立task所在的cgroupcss_set的引用

     */

    for (i = 0; i < CGROUP_SUBSYS_COUNT; i++) {

        struct cgroup *cgrp = res->subsys[i]->cgroup;

        struct cgroup_subsys *ss = subsys[i];

        atomic_inc(&cgrp->count);

        /*

         * We want to add a link once per cgroup, so we

         * only do it for the first subsystem in each

         * hierarchy

         */

        if (ss->root->subsys_list.next == &ss->sibling) {

            BUG_ON(list_empty(&tmp_cg_links));

            link = list_entry(tmp_cg_links.next,

                      struct cg_cgroup_link,

                      cgrp_link_list);

            list_del(&link->cgrp_link_list);

            list_add(&link->cgrp_link_list, &cgrp->css_sets);

            link->cg = res;

            list_add(&link->cg_link_list, &res->cg_links);

        }

    }

   

    /*似乎沒有地方會更改rootnode.subsys_list.?這裡的判斷大部份情況是滿足的*/

    if (list_empty(&rootnode.subsys_list)) {

        /*建立這個css_setdumytop的引用*/

        /* 這樣做,是為了讓新建的hierarchy能夠關聯到所有的process*/

        link = list_entry(tmp_cg_links.next,

                  struct cg_cgroup_link,

                  cgrp_link_list);

        list_del(&link->cgrp_link_list);

        list_add(&link->cgrp_link_list, &dummytop->css_sets);

        link->cg = res;

        list_add(&link->cg_link_list, &res->cg_links);

    }

    BUG_ON(!list_empty(&tmp_cg_links));

這一部份的關鍵操作都在代碼中添加了相應的註釋.如果系統中存在多個hierarchy.那麼這個process肯定也位於其它的hierarchy所對應的cgroup.因此需要在新分配的css_set中保存這些信息,也就是建立從cgroupcss_set的引用.

另外,關於ist_empty(&rootnode.subsys_list)的操作.似乎沒看到有什麼地方會更改rootnode.subsys_list.不過,如果rootnode.subsys_list不為空的話,也會在它前面的for循環中檢測出來.

總而言之.系統中有root_counthierarchy.上述的引用保存過程就會進行root_count.因此.到最後.tmp_cg_links肯定會空了.如果不為空.說明某處發生了錯誤.

 

    /*增加css_set計數*/

    css_set_count++;

 

    /* Add this cgroup group to the hash table */

    /*將其添加到全局哈希數組: css_set_table[ ]*/

    hhead = css_set_hash(res->subsys);

    hlist_add_head(&res->hlist, hhead);

 

    write_unlock(&css_set_lock);

 

    return res;

}

最後,將生成的css_set添加到哈希數組css_set_table[ ].

到這裡,task文件的操作已經分析完了.

 

7.6: notify_on_release文件操作

notify_on_release文件對應的cftype結構如下:

{

        .name = "notify_on_release",

        .read_u64 = cgroup_read_notify_on_release,

        .write_u64 = cgroup_write_notify_on_release,

        .private = FILE_NOTIFY_ON_RELEASE,

}

 

從此得知.文件的讀操作接口為cgroup_read_notify_on_release().代碼如下:

static u64 cgroup_read_notify_on_release(struct cgroup *cgrp,

                        struct cftype *cft)

{

    return notify_on_release(cgrp);

}

繼續跟進notify_on_release().如下示:

static int notify_on_release(const struct cgroup *cgrp)

{

    return test_bit(CGRP_NOTIFY_ON_RELEASE, &cgrp->flags);

}

從此可以看到,如果當前cgroup設置了CGRP_NOTIFY_ON_RELEASE標誌.就會返回1.否則.就是為0.

從當前系統中測試一下,如下:

[root@localhost cgroup]# cat notify_on_release

0

[root@localhost cgroup]#

文件內容為零.因為top_cgroup上沒有設置CGRP_NOTIFY_ON_RELEASE的標誌.

 

notify_on_release文件讀操作接口為cgroup_write_notify_on_release().代碼如下:

static int cgroup_write_notify_on_release(struct cgroup *cgrp,

                      struct cftype *cft,

                      u64 val)

{

    clear_bit(CGRP_RELEASABLE, &cgrp->flags);

    if (val)

        set_bit(CGRP_NOTIFY_ON_RELEASE, &cgrp->flags);

    else

        clear_bit(CGRP_NOTIFY_ON_RELEASE, &cgrp->flags);

    return 0;

}

從上面的代碼可以看到.如果我們寫入的是1.就會設置cgroup標誌的CGRP_NOTIFY_ON_RELEASE.否則.清除CGRP_NOTIFY_ON_RELEASE.測試如下:

[root@localhost cgroup]# echo 1 > notify_on_release

[root@localhost cgroup]# cat notify_on_release

1

[root@localhost cgroup]# echo 0 > notify_on_release

[root@localhost cgroup]# cat notify_on_release

0

[root@localhost cgroup]#

 

7.7: release_agent文件操作

release_agent只有在頂層目錄才會有.它所代表的cftype結構如下:

static struct cftype cft_release_agent = {

    .name = "release_agent",

    .read_seq_string = cgroup_release_agent_show,

    .write_string = cgroup_release_agent_write,

    .max_write_len = PATH_MAX,

    .private = FILE_RELEASE_AGENT,

};

 

由此可以看到.讀文件的接口為cgroup_release_agent_show.代碼如下:

static int cgroup_release_agent_show(struct cgroup *cgrp, struct cftype *cft,

                     struct seq_file *seq)

{

    if (!cgroup_lock_live_group(cgrp))

        return -ENODEV;

    seq_puts(seq, cgrp->root->release_agent_path);

    seq_putc(seq, '\n');

    cgroup_unlock();

    return 0;

}

從代碼中可以看到.就是打印出rootrelease_agent_path.

 

寫文件的接口為cgroup_release_agent_write().如下示:

static int cgroup_release_agent_write(struct cgroup *cgrp, struct cftype *cft,

                      const char *buffer)

{

    BUILD_BUG_ON(sizeof(cgrp->root->release_agent_path) < PATH_MAX);

    if (!cgroup_lock_live_group(cgrp))

        return -ENODEV;

    strcpy(cgrp->root->release_agent_path, buffer);

    cgroup_unlock();

    return 0;

}

由此得知.往這個文件中寫內容,就是設置rootrelease_agent_path.如下做個測試:

[root@localhost cgroup]# cat release_agent

 

[root@localhost cgroup]# echo /bin/ls > release_agent

[root@localhost cgroup]# cat release_agent

/bin/ls

[root@localhost cgroup]#

 

7.8:debug創建的文件分析

下面分析一下debug subsys中的文件.由於我們掛載的時候沒有帶noprefix.因為.debug生成的文件都帶了一個」debug_」前綴.debug創建的文件如下示:

debug.cgroup_refcount  debug.current_css_set_refcount  debug.taskcount debug.current_css_set  debug.releasable

挨個分析如下:

7.8.1: cgroup_refcount文件操作

Cgroup_refcount所代表的cftype結構如下示:

    {

        .name = "cgroup_refcount",

        .read_u64 = cgroup_refcount_read,

    },

可以看到,該文件不能寫,只能讀.讀操作接口為cgroup_refcount_read().代碼如下:

static u64 cgroup_refcount_read(struct cgroup *cont, struct cftype *cft)

{

    return atomic_read(&cont->count);

}

它就是顯示出當前cgroup的引用計數.

測試如下:

[root@localhost cgroup]# cat debug.cgroup_refcount

0

[root@localhost cgroup]#

頂層的cgroup是位於cgroupfs_root.top_cgroup.它的引用計數為0.

接下來,我們在下層創建一個子層cgroup.如下示:

[root@localhost cgroup]# mkdir /dev/cgroup/eric

[root@localhost cgroup]# cat /dev/cgroup/eric/debug.cgroup_refcount

0

[root@localhost cgroup]#

可見創建子層cgroup不會增加其引用計數.因為它只是與它的上一層cgroup構成指針指向關係.

現在我們讓子層cgroup關聯一個process

[root@localhost cgroup]# echo 1673 > /dev/cgroup/eric/tasks

[root@localhost cgroup]# cat /dev/cgroup/eric/debug.cgroup_refcount

1

[root@localhost cgroup]#

可以看到.它的計數比為了1.這裡在關聯processcss_set和所在的cgroup時增加的.

 

7.8.2: current_css_set文件操作

current_css_set對應的cftype結構如下示:

    {

        .name = "current_css_set",

        .read_u64 = current_css_set_read,

    },

可看出.它也是一個只讀的.讀接口為current_css_set_read().代碼如下:

static u64 current_css_set_read(struct cgroup *cont, struct cftype *cft)

{

    return (u64)(long)current->cgroups;

}

它就是顯示了當前process關聯的css_set的地址.

測試如下:

[root@localhost cgroup]# cat debug.current_css_set

18446744072645980768

 

7.8.3: current_css_set_refcount文件操作

current_css_set_refcount文件對應的ctype結構如下:

    {

        .name = "current_css_set_refcount",

        .read_u64 = current_css_set_refcount_read,

    },

照例.它也是只讀的.接口如下:

static u64 current_css_set_refcount_read(struct cgroup *cont,

                       struct cftype *cft)

{

    u64 count;

 

    rcu_read_lock();

    count = atomic_read(&current->cgroups->refcount);

    rcu_read_unlock();

    return count;

}

它就是顯示出與當前process關聯的css_set的引用計數.

測試如下:

[root@localhost cgroup]# cat debug.current_css_set_refcount

56

表示已經有56process關聯到這個css_set.

 

7.8.3: taskcount文件操作

Taskcount文件對應cftype結構如下:

    {

        .name = "taskcount",

        .read_u64 = taskcount_read,

    },

只讀文件.接口如下:

static u64 taskcount_read(struct cgroup *cont, struct cftype *cft)

{

    u64 count;

 

    cgroup_lock();

    count = cgroup_task_count(cont);

    cgroup_unlock();

    return count;

}

其中,子函數cgroup_task_count()我們在之前已經分析過了.它就是計算與當前cgroup關聯的process數目.這裡就不再分析了.測試如下:

[root@localhost cgroup]# cat debug.taskcount

56

 

7.8.4: releasable文件操作

Releasable文件對應的ctype結構如下示:

    {

        .name = "releasable",

        .read_u64 = releasable_read,

    },

只讀,讀接口代碼如下:

static u64 releasable_read(struct cgroup *cgrp, struct cftype *cft)

{

    return test_bit(CGRP_RELEASABLE, &cgrp->flags);

}

它用來查看當前cgroup是否有CGRP_RELEASABLE標誌.如果有.顯示為1.否則顯示為0.

測試如下:

[root@localhost cgroup]# cat debug.releasable

0

經過上面的分析.可以知道.如果往cgroup中刪除一個關聯process,就會將其設置CGRP_RELEASABLE標誌.有下面測試:

[root@localhost cgroup]# mkdir eric

[root@localhost cgroup]# cat eric/debug.releasable

0

[root@localhost cgroup]# echo 1650 > eric/tasks

[root@localhost cgroup]# echo 1701 > eric/tasks    

[root@localhost cgroup]# cat eric/debug.releasable

0

[root@localhost cgroup]# echo 1650 >tasks

[root@localhost cgroup]# cat eric/debug.releasable

1

 

到這裡為止,subsys共有的文件和debug中的文件操作就已經分析完了.其它的subsys遠遠比debug要複雜.之後再給出專題分析.詳情請關注本站更新.*^_^*

 

: notify_on_release操作

下面我們來分析在之前一直在忽略的一個問題.也就是涉及到CGRP_NOTIFY_ON_RELEASE標誌和root-> release_agent_path[]部份.

它的重用,就是在cgroup中最後的一個process離開(包括process退出.process關聯到其它同類型的cgroup),或者是在最後一個子層cgroup被移除的時候.就會調用用戶空間的一個程序.這個程序的路徑是在root-> release_agent_path[]中指定的.

下面我們從代碼的角度來跟蹤一下.

 

9.1:process退出

我們在之前在分析父子process之間的cgroup關係的時候.忽略掉了__put_css_set函數中的一個部份.現在是時候來剝開它了.

__put_css_set()被忽略的代碼片段列出,如下:

static void __put_css_set(struct css_set *cg, int taskexit)

{

    ......

    ......

    for (i = 0; i < CGROUP_SUBSYS_COUNT; i++) {

        struct cgroup *cgrp = cg->subsys[i]->cgroup;

        if (atomic_dec_and_test(&cgrp->count) &&

            notify_on_release(cgrp)) {

            if (taskexit)

                set_bit(CGRP_RELEASABLE, &cgrp->flags);

            check_for_release(cgrp);

        }

    }

    ......

    ......

}

首先,process退出時,調用__put_css_set.taskexit參數是為1,因此在這裡,它會將cgroupflagCGRP_RELEASABLE位置1.

atomic_dec_and_test(&cgrp->count)返回為真的話,說明process所屬的cgroup中已經沒有其它的process.因此即將要退出的子process就是cgroup中的最後一個process.

notify_on_release(cgrp)代碼如下:

static int notify_on_release(const struct cgroup *cgrp)

{

    return test_bit(CGRP_NOTIFY_ON_RELEASE, &cgrp->flags);

}

它用來判斷cgroup有沒有設定CGRP_NOTIFY_ON_RELEASE標誌

綜合上面的分析.如果cgroup中最後一個process退出.cgroup設定了CGRP_NOTIFY_ON_RELEASE標誌.流程就會轉到check_for_release().該函數代碼如下:

static void check_for_release(struct cgroup *cgrp)

{

    /* All of these checks rely on RCU to keep the cgroup

     * structure alive */

    if (cgroup_is_releasable(cgrp) && !atomic_read(&cgrp->count)

        && list_empty(&cgrp->children) && !cgroup_has_css_refs(cgrp)) {

        /* Control Group is currently removeable. If it's not

         * already queued for a userspace notification, queue

         * it now */

        int need_schedule_work = 0;

        spin_lock(&release_list_lock);

        if (!cgroup_is_removed(cgrp) &&

            list_empty(&cgrp->release_list)) {

            list_add(&cgrp->release_list, &release_list);

            need_schedule_work = 1;

        }

        spin_unlock(&release_list_lock);

        if (need_schedule_work)

            schedule_work(&release_agent_work);

    }

}

首先,在這裡必須要滿足以下四個條件才能繼續下去:

1:cgroup_is_releasable()返回1.

代碼如下:

static int cgroup_is_releasable(const struct cgroup *cgrp)

{

    const int bits =

        (1 << CGRP_RELEASABLE) |

        (1 << CGRP_NOTIFY_ON_RELEASE);

    return (cgrp->flags & bits) == bits;

}

它表示當前cgroup是含含有CGRP_RELEASABLECGRP_NOTIFY_ON_RELEASE標誌.結合我們在上面分析的. CGRP_RELEASABLE標誌是process在退出是就會設置的.

 

2:cgroup的引用計數為0

3:cgroup沒有子層cgroup

4: cgroup_has_css_refs()返回0.代碼如下:

static int cgroup_has_css_refs(struct cgroup *cgrp)

{

    int i;

    for (i = 0; i < CGROUP_SUBSYS_COUNT; i++) {

        struct cgroup_subsys *ss = subsys[i];

        struct cgroup_subsys_state *css;

        /* Skip subsystems not in this hierarchy */

        if (ss->root != cgrp->root)

            continue;

        css = cgrp->subsys[ss->subsys_id];

        if (css && atomic_read(&css->refcnt))

            return 1;

    }

    return 0;

}

也就是說,cgroup關聯的css_set引用計數必須要為0

 

滿足上面幾個條件之後.就說明該cgroup是可以釋放的.因此將cgroup鏈接到了release_list.接著調度了工作隊列.在工作隊列中會完成餘下的工作.

下面跟蹤看看這個工作隊列是怎麼處理餘下任務的.

release_agent_work定義如下:

static DECLARE_WORK(release_agent_work, cgroup_release_agent);

該工作隊列對應的處理函數為cgroup_release_agent().代碼如下:

static void cgroup_release_agent(struct work_struct *work)

{

    BUG_ON(work != &release_agent_work);

    mutex_lock(&cgroup_mutex);

    spin_lock(&release_list_lock);

    /*遍歷鏈表,直到其為空*/

    while (!list_empty(&release_list)) {

        char *argv[3], *envp[3];

        int i;

        char *pathbuf = NULL, *agentbuf = NULL;

        /*取得鏈表項對應的cgroup*/

        struct cgroup *cgrp = list_entry(release_list.next,

                            struct cgroup,

                            release_list);

        /*cgrouprelease_list中斷開*/

        list_del_init(&cgrp->release_list);

        spin_unlock(&release_list_lock);

        /*cgroup的路徑存放到pathbuf*/

        pathbuf = kmalloc(PAGE_SIZE, GFP_KERNEL);

        if (!pathbuf)

            goto continue_free;

        if (cgroup_path(cgrp, pathbuf, PAGE_SIZE) < 0)

            goto continue_free;

        /*agentbuf存放release_agent_path的內容*/

        agentbuf = kstrdup(cgrp->root->release_agent_path, GFP_KERNEL);

        if (!agentbuf)

            goto continue_free;

        /*初始化運行參數和環境變量*/

        i = 0;

        argv[i++] = agentbuf;

        argv[i++] = pathbuf;

        argv[i] = NULL;

 

        i = 0;

        /* minimal command environment */

        envp[i++] = "HOME=/";

        envp[i++] = "PATH=/sbin:/bin:/usr/sbin:/usr/bin";

        envp[i] = NULL;

 

        /* Drop the lock while we invoke the usermode helper,

         * since the exec could involve hitting disk and hence

         * be a slow process */

         /*調用用戶空間的process*/

        mutex_unlock(&cgroup_mutex);

        call_usermodehelper(argv[0], argv, envp, UMH_WAIT_EXEC);

        mutex_lock(&cgroup_mutex);

 continue_free:

        kfree(pathbuf);

        kfree(agentbuf);

        spin_lock(&release_list_lock);

    }

    spin_unlock(&release_list_lock);

    mutex_unlock(&cgroup_mutex);

}

該函數遍歷release_list中的cgroup.然後以其路徑做為參數.調用root->release_agent_path對應的程序.

我們來做如下的實驗:

為了配合這次實驗.必須要寫兩個測試的程序.代碼如下:

Test.c

 

#include <stdio.h>

#include <stdlib.h>

 

main()

{

        int i = 30;

        while(i){

                i--;

                sleep(1);

        }

}

 

這個process睡眠30s之後退出.編譯成test

 

另外一個程序代碼如下:

Main.c

#include <stdio.h>

#include <stdlib.h>

 

int main(int argc,char *argv[])

{

        char buf[125] = "";

        int i = 0;

 

        sprintf(buf,"rm -f /var/eric_test");

        system(buf);

 

        while(i < argc){

                sprintf(buf,"echo %s >> /var/eric_test",argv[i]);

                system(buf);

                i++;

        }

 

}

它就是將調用參數輸出到/var/eric_test下面.

下面就可以開始我們的測試了.掛載目錄下已經有一個子層cgroup.如下示:

.

|-- debug.cgroup_refcount

|-- debug.current_css_set

|-- debug.current_css_set_refcount

|-- debug.releasable

|-- debug.taskcount

|-- eric

|   |-- debug.cgroup_refcount

|   |-- debug.current_css_set

|   |-- debug.current_css_set_refcount

|   |-- debug.releasable

|   |-- debug.taskcount

|   |-- notify_on_release

|   `-- tasks

|-- notify_on_release

|-- release_agent

`-- tasks

 

接下來設置realesse_agent_pathCGRP_NOTIFY_ON_RELEASE標誌,指令如下:

[root@localhost cgroup]# echo /root/main > release_agent

[root@localhost cgroup]# echo 1 > eric/notify_on_release

下面往子層cgroup中添加一個process.指令如下:

[root@localhost cgroup]# /root/test &

[1] 4350

[root@localhost cgroup]# echo 4350 > eric/tasks

[root@localhost cgroup]#

[1]+  Done                    /root/test

/root/test運行完之後.就會進行notify_on_release的操作了.印證一下:

[root@localhost cgroup]# cat /var/eric_test

/root/main

/eric

一切都如我們上面分析的一樣

 

9.2:取消processcgroup的關聯

cgroup中的最後一個process取消關聯的時候,也會有notify_on_release過程.見下面的代碼片段:

int cgroup_attach_task(struct cgroup *cgrp, struct task_struct *tsk)

{

    int retval = 0;

    struct cgroup_subsys *ss;

    struct cgroup *oldcgrp;

    struct css_set *cg = tsk->cgroups;

    ......

    ......

    set_bit(CGRP_RELEASABLE, &oldcgrp->flags);

    synchronize_rcu();

    put_css_set(cg);

}

這個函數我們在之前分析過,不過也把notify_on_release的過程去掉了.現在也把它加上.

代碼中的cg是指向process原本所引用的css_set

Oldcgrp是過程之前所在的cgroup

在代碼中,會將oldcgrp標誌設為CGRP_RELEASABLE.之後也會調用put_css_set().put_css_set()就是我們在上面分析的過程了.如果cgroup為空的話,就會產生notify_on_release的操作.

同樣做個測試:

接著上面的測試環境.我們先來看下環境下的相關文件內容:

[root@localhost cgroup]# cat release_agent

/root/main

[root@localhost cgroup]# cat eric/tasks

[root@localhost cgroup]# cat eric/notify_on_release

1

[root@localhost cgroup]# pwd

/dev/cgroup

好了,測試開始了:

[root@localhost cgroup]# rm -rf /var/eric_test

[root@localhost cgroup]# echo 1701 > eric/tasks

[root@localhost cgroup]# echo 1701 >tasks

[root@localhost cgroup]# cat /var/eric_test

/root/main

/eric

在上面的測試過程中.為了避免影響測試效果.先將/var/eric_test文件刪了.然後將process1701關聯到eric所表示的cgroup.然後再把1701再加最上層cgroup.這樣就會造成eric下關聯process為空.相應的會發生notify_on_release過程.上面的測試也印證了這一說話.

 

9.3:移除cgroup

當移除cgroup下的最後一個子層cgroup.也會發生notify_on_release.

看一下移除cgroup時的代碼片段:

static int cgroup_rmdir(struct inode *unused_dir, struct dentry *dentry)

{

    ......

    ......

    set_bit(CGRP_RELEASABLE, &parent->flags);

    check_for_release(parent);

    ......

}

代碼中,parent表示cgroup的上一層.在移除cgroup,會設置上一層的cgroup標誌的CGRP_RELEASABLE.然後流程同樣會轉入到check_for_release().這樣,如果上一層cgroup是空的話.就會生notify_on_release操作了.

測試如下:

還是用上層的測試環境.先來看一下初始環境:

[root@localhost cgroup]# pwd

/dev/cgroup

[root@localhost cgroup]# cat release_agent

/root/main

[root@localhost cgroup]# cat eric/notify_on_release

1

eric下面再加一層cgroup.

[root@localhost cgroup]# mkdir eric/test

[root@localhost cgroup]# tree

.

|-- debug.cgroup_refcount

|-- debug.current_css_set

|-- debug.current_css_set_refcount

|-- debug.releasable

|-- debug.taskcount

|-- eric

|   |-- debug.cgroup_refcount

|   |-- debug.current_css_set

|   |-- debug.current_css_set_refcount

|   |-- debug.releasable

|   |-- debug.taskcount

|   |-- notify_on_release

|   |-- tasks

|   `-- test

|       |-- debug.cgroup_refcount

|       |-- debug.current_css_set

|       |-- debug.current_css_set_refcount

|       |-- debug.releasable

|       |-- debug.taskcount

|       |-- notify_on_release

|       `-- tasks

|-- notify_on_release

|-- release_agent

`-- tasks

 

2 directories, 22 files

接著運行如下指令:

[root@localhost cgroup]# rm -rf /var/eric_test

[root@localhost cgroup]# rmdir eric/test/

[root@localhost cgroup]# cat /var/eric_test

/root/main

/eric

如上所示.eric下的唯一一個cgroup移除的時候.就發生了notity_on_release過程.

 

:cgroupproc節點

10.1:/proce/cgroups

在前面分析cgroup初始化的時候.cgroup_init()中有下面代碼片段:

int __init cgroup_init(void)

{

    ......

    ......

    proc_create("cgroups", 0, NULL, &proc_cgroupstats_operations)

    ......

    ......

}

也就是說.會在proc根目錄下創建一個名為cgroups的文件.如下示:

[root@localhost cgroup]# ls /proc/cgroups  

/proc/cgroups

接下來就來分析這個文件的操作.

該文件對應的操作集為

proc_cgroupstats_operations.定義如下:

static struct file_operations proc_cgroupstats_operations = {

    .open = cgroupstats_open,

    .read = seq_read,

    .llseek = seq_lseek,

    .release = single_release,

}

從上面看到,這個文件是只讀的.

先來看open時的操作,對應接口為cgroupstats_open.代碼如下:

static int cgroupstats_open(struct inode *inode, struct file *file)

{

    return single_open(file, proc_cgroupstats_show, NULL);

}

Single_open()函數十分簡單.它也是sequences file中提供的一個接口.有關sequences file部份我們在上面已經分析過了. 這裡就不再詳細分析了.它將seq_fileshow操作指向了proc_cgroupstats_show.

我們在上面的proc_cgroupstats_operations結構中可看到,它提供的read操作為seq_read().它就是調用seq_file中的相關操作.open的時候,已經將seq_fileshow接口指向了proc_cgroupstats_show().代碼如下:

static int proc_cgroupstats_show(struct seq_file *m, void *v)

{

    int i;

 

    seq_puts(m, "#subsys_name\thierarchy\tnum_cgroups\tenabled\n");

    mutex_lock(&cgroup_mutex);

    for (i = 0; i < CGROUP_SUBSYS_COUNT; i++) {

        struct cgroup_subsys *ss = subsys[i];

        seq_printf(m, "%s\t%lu\t%d\t%d\n",

               ss->name, ss->root->subsys_bits,

               ss->root->number_of_cgroups, !ss->disabled);

    }

    mutex_unlock(&cgroup_mutex);

    return 0;

}

從代碼中看到,它就是將系統中每subsys名稱.所在hierarchy的位碼. Hierarchy下面的cgroup數目和subsys的啟用狀態.

測試如下:

[root@localhost cgroup]# cat /proc/cgroups

#subsys_name    hierarchy       num_cgroups     enabled

cpuset  0       1       1

debug   2       2       1

ns      0       1       1

cpuacct 0       1       1

memory  0       1       1

devices 0       1       1

freezer 0       1       1

從這裡可以看到所有的subsyshierarchy的情況.在上面顯示的debug和其它的subsys不同.是因為用的是之前測試notify_on_release的環境.如下示:

[root@localhost cgroup]# tree ../cgroup/

../cgroup/

|-- debug.cgroup_refcount

|-- debug.current_css_set

|-- debug.current_css_set_refcount

|-- debug.releasable

|-- debug.taskcount

|-- eric

|   |-- debug.cgroup_refcount

|   |-- debug.current_css_set

|   |-- debug.current_css_set_refcount

|   |-- debug.releasable

|   |-- debug.taskcount

|   |-- notify_on_release

|   `-- tasks

|-- notify_on_release

|-- release_agent

`-- tasks

 

1 directory, 15 files

 

10.2:procprocess鏡像中的cgroup

除了在proc頂層目錄創建cgroup.另外在每個process鏡像下都有一個cgroup的文件.如下示:

[root@localhost cgroup]# ls /proc/648/cgroup

/proc/648/cgroup

 

來看一下這個文件對應的操作,如下示:

static const struct pid_entry tid_base_stuff[] = {

    ......

    ......

#ifdef CONFIG_CGROUPS

    REG("cgroup",  S_IRUGO, cgroup),

#endif

......

}

 

#define REG(NAME, MODE, OTYPE)              \

    NOD(NAME, (S_IFREG|(MODE)), NULL,       \

        &proc_##OTYPE##_operations, {})

從上面可以看到.Cgroup對應的操作為&proc_cgroup_operations

定義如下:

struct file_operations proc_cgroup_operations = {

    .open       = cgroup_open,

    .read       = seq_read,

    .llseek     = seq_lseek,

    .release    = single_release,

};

Open對應的操作為cgroup_open.定義如下:

static int cgroup_open(struct inode *inode, struct file *file)

{

    struct pid *pid = PROC_I(inode)->pid;

    return single_open(file, proc_cgroup_show, pid);

}

又見到single_open()了.如上面的分析一樣,read操作的時候會轉入到proc_cgroup_show().代碼如下:

static int proc_cgroup_show(struct seq_file *m, void *v)

{

    struct pid *pid;

    struct task_struct *tsk;

    char *buf;

    int retval;

    struct cgroupfs_root *root;

 

    retval = -ENOMEM;

    buf = kmalloc(PAGE_SIZE, GFP_KERNEL);

    if (!buf)

        goto out;

 

    retval = -ESRCH;

    pid = m->private;

    tsk = get_pid_task(pid, PIDTYPE_PID);

    if (!tsk)

        goto out_free;

 

    retval = 0;

 

    mutex_lock(&cgroup_mutex);

 

    /*遍歷所有的cgroupfs_root*/

    for_each_root(root) {

        struct cgroup_subsys *ss;

        struct cgroup *cgrp;

        int subsys_id;

        int count = 0;

 

        /* Skip this hierarchy if it has no active subsystems */

        /*如果hierarchy中沒有subsys.就繼續下一個rootnode就是這樣的情況*/

        if (!root->actual_subsys_bits)

            continue;

        /*打印hierarchy中的subsys位圖*/

        seq_printf(m, "%lu:", root->subsys_bits);

        /*打印hierarchy中的subsys名稱*/

        for_each_subsys(root, ss)

            seq_printf(m, "%s%s", count++ ? "," : "", ss->name);

        seq_putc(m, ':');

        /*process所在cgrouppath*/

        get_first_subsys(&root->top_cgroup, NULL, &subsys_id);

        cgrp = task_cgroup(tsk, subsys_id);

        retval = cgroup_path(cgrp, buf, PAGE_SIZE);

        if (retval < 0)

            goto out_unlock;

        seq_puts(m, buf);

        seq_putc(m, '\n');

    }

 

out_unlock:

    mutex_unlock(&cgroup_mutex);

    put_task_struct(tsk);

out_free:

    kfree(buf);

out:

    return retval;

}

它的核心操作在這個for循環中,它的操作在註釋中已經詳細的說明了.在這裡不做詳細分析.

我將虛擬機重啟了 *^_^*,所以現在的環境不是我們之前的測試環境了

測試一下

[root@localhost ~]# cat /proc/646/cgroup

[root@localhost ~]#

說明當前系統中還沒有hierarchy

接下來掛載上一個:

[root@localhost ~]# mkdir /dev/cgroup

[root@localhost ~]# mount -t cgroup cgroup -o debug /dev/cgroup/

[root@localhost ~]# cat /proc/6

6/   609/ 646/

[root@localhost ~]# cat /proc/646/cgroup

2:debug:/

[root@localhost ~]#

從上面可以看到.系統已經有一個hierarchy.且綁定的是debug subsys.當前process是位於它的頂層.

繼續測試:

[root@localhost ~]# mkdir /dev/cgroup/eric

[root@localhost ~]# echo 646 > /dev/cgroup/eric/tasks

[root@localhost ~]# cat /proc/646/cgroup                       

2:debug:/eric

[root@localhost ~]#

可以看到,當前process是位於eric這個cgroup中.

 

十一:小結

在這一節裡,用大篇幅詳細的描述了整個cgroup的框架.cgroup框架並不複雜,只是其中的資料結構和大量的全局變量弄的頭昏眼花.因此理順這些資料結構和變量是閱讀cgroup代碼的關鍵.另外在cgroup中對於RCUrw_mutex的使用也有值得推敲的地方.不過由於篇幅關係,就不再分析這一部份.在接下來專題裡.cgroup框架為基礎來分析幾個重要的subsys.

huenlil 發表在 痞客邦 PIXNET 留言(0) 人氣()