Linux Kernel Cgroups源码浅析

最新推荐文章于 2025-06-13 11:11:46 发布

原创

最新推荐文章于 2025-06-13 11:11:46 发布 · 1.8w 阅读

14 ·

CC 4.0 BY-SA版权

文章标签：

#linux kernel #cgroups #源码

本文详细介绍了Linux内核的Cgroups机制，包括其功能、基本概念、层级结构、子系统和源码分析。Cgroups用于限制、记录和隔离进程组的资源使用，如CPU、内存、IO等。文章还探讨了Cgroups与任务的关联、与子系统的交互，以及各个典型子系统的功能，如blkio、cpu、cpuacct等。通过对内核源码的解读，解析了Cgroups如何实现资源控制和任务管理。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

本文是我几个月前在研究linux kernel Cgroups时整理的。文中大部分的理论知识是从网上各种贴子solo的，源码分析部分，我是基于kernel 4.4.19的代码进行解读分析的，各个内核版本之间应该几乎没啥差别。了解内核中Cgroups的知识，对理解docker底层原理还是有帮助的。

介绍

Cgroups是control groups的缩写，是Linux内核提供的一种可以限制、记录、隔离进程组（process groups）所使用的物理资源（如：cpu,memory,IO等等）的机制。

Cgroups的功能

限制进程组可以使用的资源数量（Resource limiting ）。比如：memory子系统可以为进程组设定一个memory使用上限，一旦进程组使用的内存达到限额再申请内存，就会出发OOM（out of memory）。
进程组的优先级控制（Prioritization ）。比如：可以使用cpu子系统为某个进程组分配特定cpu share。
记录进程组使用的资源数量（Accounting ）。比如：可以使用cpuacct子系统记录某个进程组使用的cpu时间。
进程组隔离（Isolation）。比如：使用ns子系统可以使不同的进程组使用不同的namespace，以达到隔离的目的，不同的进程组有各自的进程、网络、文件系统挂载空间。
进程组控制（Control）。比如：使用freezer子系统可以将进程组挂起和恢复。

基本概念：

任务（task）。在cgroups中，任务就是系统的一个进程。
控制族群（control group）。
控制族群就是一组按照某种标准划分的进程。Cgroups中的资源控制都是以控制族群为单位实现。一个进程可以加入到某个控制族群，也从一个进程组迁移到另一个控制族群。一个进程组的进程可以使用cgroups以控制族群为单位分配的资源，同时受到cgroups以控制族群为单位设定的限制。
层级（hierarchy）。控制族群可以组织成hierarchical的形式，既一颗控制族群树。控制族群树上的子节点控制族群是父节点控制族群的孩子，继承父控制族群的特定的属性。
子系统（subsytem）。一个子系统就是一个资源控制器，比如cpu子系统就是控制cpu时间分配的一个控制器。子系统必须附加（attach）到一个层级上才能起作用，一个子系统附加到某个层级以后，这个层级上的所有控制族群都受到这个子系统的控制。

Rules

一个hierarchy可以有多个 subsystem (mount 的时候hierarchy可以attach多个subsystem)
一个已经被挂载的 subsystem 只能被再次挂载在一个空的 hierarchy 上 (已经mount一个subsystem的hierarchy不能挂载一个已经被其它hierarchy挂载的subsystem)。
每个task只能在一同个hierarchy的唯一一个cgroup里(不能在同一个hierarchy下有超过一个cgroup的tasks里同时有这个进程的pid)。
子进程在被fork出时自动继承父进程所在cgroup，但是fork之后就可以按需调整到其他cgroup。
其他
- 限制一个task的唯一方法就是将其加入到一个cgroup的task里。
- 多个subsystem可以挂载到一个hierarchy里, 然后通过不同的cgroup中的subsystem参数来对不同的task进行限额。
- 如果一个hierarchy有太多subsystem，可以考虑重构 - 将subsystem挂到独立的hierarchy; 相应的, 可以将多个hierarchy合并成一个hierarchy。
- 因为可以只挂载少量subsystem, 可以实现只对task单个方面的限额; 同时一个task可以被加到多个hierarchy中，从而实现对多个资源的控制。

Cgroups层级结构

这里写图片描述
上图中的”M×N Linkage”说明的是css_set通过辅助数据结构可以与 cgroups 节点进行多对多的关联。但是 cgroups 的实现不允许css_set同时关联同一个cgroups层级结构下多个节点。这是因为 cgroups 对同一种资源不允许有多个限制配置。
一个css_set关联多个 cgroups 层级结构的节点时，表明需要对当前css_set下的进程进行多种资源的控制。而一个 cgroups 节点关联多个css_set时，表明多个css_set下的进程列表受到同一份资源的相同限制。

典型的Cgroups子系统介绍

blkio – 这个子系统为块设备设定输入/输出限制，比如物理设备（磁盘，固态硬盘，USB 等等）。
cpu – 这个子系统使用调度程序提供对 CPU 的 cgroup 任务访问。
cpuacct – 这个子系统自动生成 cgroup 中任务所使用的 CPU 报告。
cpuset – 这个子系统为 cgroup 中的任务分配独立 CPU（在多核系统）和内存节点。
devices – 这个子系统可允许或者拒绝 cgroup 中的任务访问设备。
freezer – 这个子系统挂起或者恢复 cgroup 中的任务。
memory – 这个子系统设定 cgroup 中任务使用的内存限制，并自动生成由那些任务使用的内存资源报告。
net_cls – 这个子系统使用等级识别符（classid）标记网络数据包，可允许 Linux 流量控制程序（tc）识别从具体 cgroup 中生成的数据包。
ns – 名称空间子系统。

源码分析

如同namespace一样，线程Task的结构体struct task_struct中，必定有cgroups信息：

linux-4.4.19/include/linux/sched.h #1668

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

    // ...
}

RCU(Read-Copy Update)是一种linux内核中一种锁机制，顾名思义就是读-拷贝修改，它是基于其原理命名的。对于被RCU保护的共享数据结构，读者不需要获得任何锁就可以访问它，但写者在访问它时首先拷贝一个副本，然后对副本进行修改，最后使用一个回调（callback）机制在适当的时机把指向原来数据的指针重新指向新的被修改的数据。这个时机就是所有引用该数据的CPU都退出对共享数据的操作。

每个进程中，都对应有一个css_set结构体，css_set其实就是cgroup_subsys_state对象的集合，而每个cgroup_subsys_state代表一个subsystem。下面是css_set结构体的定义：
linux-4.4.19/include/linux/cgroup-defs.h #154

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;

    /*
     * Lists running through all tasks using this cgroup group.
     * mg_tasks lists tasks which belong to this cset but are in the
     * process of being migrated out or in.  Protected by
     * css_set_rwsem, but, during migration, once tasks are moved to
     * mg_tasks, it can be read safely while holding cgroup_mutex.
     */
    struct list_head tasks;
    struct list_head mg_tasks;

    /*
     * List of cgrp_cset_links pointing at cgroups referenced from this
     * css_set.  Protected by css_set_lock.
     */
    struct list_head cgrp_links;

    /* the default cgroup associated with this css_set */
    struct cgroup *dfl_cgrp;

    /*
     * 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).
     */
    struct cgroup_subsys_state *subsys[CGROUP_SUBSYS_COUNT];

    /*
     * List of csets participating in the on-going migration either as
     * source or destination.  Protected by cgroup_mutex.
     */
    struct list_head mg_preload_node;
    struct list_head mg_node;

    /*
     * If this cset is acting as the source of migration the following
     * two fields are set.  mg_src_cgrp is the source cgroup of the
     * on-going migration and mg_dst_cset is the destination cset the
     * target tasks on this cset should be migrated to.  Protected by
     * cgroup_mutex.
     */
    struct cgroup *mg_src_cgrp;
    struct css_set *mg_dst_cset;

    /*
     * On the default hierarhcy, ->subsys[ssid] may point to a css
     * attached to an ancestor instead of the cgroup this css_set is
     * associated with.  The following node is anchored at
     * ->subsys[ssid]->cgroup->e_csets[ssid] and provides a way to