linux组调度浅析 cgroupd 多个进程组 多个cgroup

Linux cgroups是一种进程资源隔离的技术，namespace是进程的网络资源隔离的技术，它们合在一块也就有了lxc项目，所以从理论上讲，lxc会比kvm性能高得多。因为lxc的每个虚机就是host操作系统的每一个隔离后的进程，并且这些进程是由host操作系统调度的，性能和host操作系统相差不会太多。唯一的缺点是lxc的隔离性不会很好，例如host机器用什么操作系统，lxc也是什么操作系统，再如在lxc中，host操作系统上的root用户可以操纵每一个lxc的虚机。当然，对于私有云，隔离性相比性能倒是其次的，是可以一用的。

离题了，说到Linux cgroups技术，还有一个非常有意思的项目，叫CoreOS。它居然利用linux cgroups技术来无缝的升级。在另一个cgroups上升级好，然后再切换过去。这个网页“http://www.csdn.net/article/2013-08-22/2816672-coreos-the-new-linux”对它的描述如下：

CoreOS有两个root分区，我们暂且称其为root A和root B。CoreOS会与更新服务进行交互，查找更新并自动下载可用的更新，如果初始状态下，系统在root A下启动，更新就会被安装到root B，重新在root B下启动系统就可以完成更新。这个个过程中，被更新的机器不需要从负载集群中移除。同时，为了保证其它应用程序不被打断，CoreOS会通过Linux cgroups限制更新过程中的硬盘和网络I/O。

笔者认为，这种技术也完全可以用在OpenStack上，用它来无缝升级。升级成功，自动切换；升级不成功，回退也容易。由于cgroups的隔离性对原有系统不会有任何影响。

cgroup与组调度

linux内核实现了control group功能（cgroup，since linux 2.6.24），可以支持将进程分组，然后按组来划分各种资源。比如：group-1拥有30%的CPU和50%的磁盘IO、group-2拥有10%的CPU和20%的磁盘IO、等等。具体参阅cgroup相关文章。

 

cgroup支持很多种资源的划分，CPU资源就是其中之一，这就引出了组调度。

linux内核中，传统的调度程序是基于进程来调度的。假设用户A和B共用一台机器，这台机器主要用来编译程序。我们可能希望A和B能公平的分享CPU资源，但是如果用户A使用make -j8（8个线程并行make）、而用户B直接使用make的话（假设他们的make程序都使用了默认的优先级），A用户的make程序将产生8倍于B用户的进程数，从而占用（大致）8倍于B用户的CPU。因为调度程序是基于进程的，A用户的进程越多，被调度的机率就越大，就越具有对CPU的竞争力。

如何保证A、B用户公平分享CPU呢？组调度就能做到这一点。把属于用户A和B的进程各分为一组，调度程序将先从两个组中选择一个组，再从选中的组中选择一个进程来执行。如果两个组被选中的机率相当，那么用户A和B将各占有约50%的CPU。

 

相关数据结构 

 

在linux内核中，使用task_group结构来管理组调度的组。所有存在的task_group组成一个树型结构（与cgroup的目录结构相对应）。

一个task_group可以包含具有任意调度类别的进程（具体来说是实时进程和普通进程两种类别），于是task_group需要为每一种调度策略提供一组调度结构。这里所说的一组调度结构主要包括两个部分，调度实体和运行队列（两者都是每CPU一份的）。调度实体会被添加到运行队列中，对于一个task_group，它的调度实体会被添加到其父task_group的运行队列。

为什么要有调度实体这样的东西呢？因为被调度的对象有task_group和task两种，所以需要一个抽象的结构来代表它们。如果调度实体代表task_group，则它的my_q字段指向这个调度组对应的运行队列；否则my_q字段为NULL，调度实体代表task。在调度实体中与my_q相对的是X_rq（具体是针对普通进程的cfs_rq和针对实时进程的rt_rq），前者指向这个组自己的运行队列，里面会放入它的子节点；后者指向这个组的父节点的运行队列，也就是这个调度实体应该被放入的运行队列。</