出现的背景
总结来说是希望不同分组的任务在高负载下能分配可控比例的CPU资源。为什么会有这个需求呢，假设多用户计算机系统每个用户的所有任务划分到一个分组中，A用户90个任务，而B用户只有10个任务（这100个任务假设都是优先级一样的普通进程），在CPU完全跑满的情况下，那么A用户将占90%的CPU时间，而B用户只占到了10%的CPU时间，这对B用户显然是不公平的。再或者同一个用户，既想-j64快速编译，又不想被编译任务影响使用体验，也可将编译任务设置到对应分组中，限制其CPU资源。组调度的引入，正是解决此问题的，即可以将任务分配给不同的任务组来实现CPU资源的合理利用。
我们举个例子来进一步阐述一下上面这段话。现在的计算机都支持多用户登录，如果一台计算机被两个用户A和B同时使用，假设用户A运行8个进程，用户B运行2个进程，按照之前对CFS的理解，CFS的调度粒度都是一个个的进程，我们认为用户A获得80%的cpu时间，用户B获得20%的cpu时间。随着用户A不停的增加运行进程数量，用户B可使用的CPU时间越来越少，这就完全不符合我们的预期了。因此，我们引入了组调度(Group Scheduling)的概念。我们将一个用户的任务放在同一个任务组中，这样用户A和用户B各获得50%cpu时间。用户A中的每个进程获得6.25%（50% / 8）cpu时间，用户B的每个进程获得25%（50% / 2）cpu时间，这样的结果是符合我们预期的。
task group
前面我们说过，CFS调度器管理的是调度实体。每一个进程通过task_struct描述，task_struct对应一个调度实体sched_entity。针对task_struct对应的调度实体，我们称之为task se。现在我们引入任务组的概念，我们使用task_group描述一个任务组，这个组管理组内所有的进程。因为CFS就绪队列管理的单位是调度实体，因此，task_group也脱离不了sched_entity，即task_group也映射为一个调度实体，我们称这种调度实体为group se。
/* Task group related information */
/*
* 组调度，Linux支持将任务分组来对CPU资源进行分配管理。
* 该结构中为系统中的每个CPU都分配了struct sched_entity调度实体和struct cfs_rq运行队列，
* 其中struct sched_entity用于参与CFS的调度。
*/
struct task_group {
struct cgroup_subsys_state css;
#ifdef CONFIG_FAIR_GROUP_SCHED
/* schedulable entities of this group on each CPU */
/*
* 所以se代表cpu数量个group se。
* 在alloc_fair_sched_group()中进程初始化及分配内存。
*/
struct sched_entity **se;
/* runqueue "owned" by this group on each CPU */
struct cfs_rq **cfs_rq; // 每一个se[cpu]对应一个group cfs_rq。
unsigned long shares; // 整个调度组的权重。
#ifdef CONFIG_SMP
/*
* load_avg can be heavily contended at clock tick time, so put
* it in its own cacheline separated from the fields above which
* will also be accessed at each tick.
*/
atomic_long_t load_avg ____cacheline_aligned; // 整个tg的负载贡献总和。
#endif
#endif
struct cfs_bandwidth cfs_bandwidth; // cpu带宽控制
};
struct task_group root_task_group;
task group与cpu rq的cfs_rq的关系
现在我们来详细说一下这张图：
系统启动后默认有一个root_task_group，管理系统中最顶层CFS就绪队列cfs_rq（即cpu rq对应的CFS就绪队列），对应上图即为root tg的cfs_rq[cpu1]和cfs_rq[cpu2]。
cpu2 rq的cfs_rq队列包含9个task se和一个group se，此group se又包含9个task se，且此group se会对应一个task group，即有几层group se，就会有几层tg(不包含root tg)。
tg的parent指向了上一级tg，se维护了cpu数量的group se，cfs_rq[cpu]维护了对应的group se下属的se。
cfs_rq的nr_running：就绪队列上调度实体的个数（包括task se和group se，比如上图中的cpu rq的cfs_rq的task se个数为9，group se个数为1，则nr_running为10）。
cfs_rq的h_nr_running：就绪队列上真实的调度实体的个数（比如上图中的cpu rq的cfs_rq的task se个数为9，group se个数为1（group se中包含9个task se，则），则h_nr_running为18）。
组进程调度
组内的进程该如何调度呢？通过上面的分析，我们可以通过cpu rq的CFS就绪队列（也称根就绪队列）一层层往下遍历选择合适进程。例如，先从根就绪队列选择适合运行的group se，然后找到对应的group cfs_rq，再从group cfs_rq上选择task se。在CFS调度类中，选择进程的函数是pick_next_task_fair()。
struct task_struct *
pick_next_task_fair(struct rq *rq, struct task_struct *prev, struct rq_flags *rf)
{
struct cfs_rq *cfs_rq = &rq->cfs; // 从per-cpu rq中获取cfs就绪队列
struct sched_entity *se;
struct task_struct *p;
int new_tasks;
again:
if (!sched_fair_runnable(rq)) // 判断per-cpu rq的cfs就绪队列上是否还有调度实体，若无则选择idle调度器。
goto idle;
#ifdef CONFIG_FAIR_GROUP_SCHED
if (!prev || prev->sched_class != &fair_sched_class)
goto simple;
/*
* Because of the set_next_buddy() in dequeue_task_fair() it is rather
* likely that a next task is from the same cgroup as the current.
*
* Therefore attempt to avoid putting and setting the entire cgroup
* hierarchy, only change the part that actually changes.
*/
do {
struct sched_entity *curr = cfs_rq->curr; // 获取当前正在cpu上运行的调度实体。
/*
* Since we got here without doing put_prev_entity() we also
* have to consider cfs_rq->curr. If it is still a runnable
* entity, update_curr() will update its vruntime, otherwise
* forget we've ever seen it.
*/
if (curr) {
if (curr->on_rq)
update_curr(cfs_rq);
else
curr = NULL;
/*
* This call to check_cfs_rq_runtime() will do the
* throttle and dequeue its entity in the parent(s).
* Therefore the nr_running test will indeed
* be correct.
*/
if (unlikely(check_cfs_rq_runtime(cfs_rq))) {
cfs_rq = &rq->cfs;
if (!cfs_rq->nr_running)
goto idle;
goto simple;
}
}
se = pick_next_entity(cfs_rq, curr); // 从rq的cfs队列中选取虚拟运行时间最小的调度实体。
cfs_rq = group_cfs_rq(se); // 返回se->my_q成员（即获取se的就绪队列）。如果是task se，则返回NULL；如果是group se，则返回group se中的csf_rq就绪队列。
} while (cfs_rq); // 如果是group se，则需要继续在group se中的cfs_rq上选择虚拟运行时间最小的se，直到找到可以最小虚拟运行时间的task se。
p = task_of(se); // 获取调度实体se对应的进程p。
return p;
}
组进程抢占
组进程抢占即为周期性调度，会调用task_tick_fair()函数。
/*
* 周期性调度
*/
static void task_tick_fair(struct rq *rq, struct task_struct *curr, int queued)
{
struct cfs_rq *cfs_rq;
struct sched_entity *se = &curr->se; //
for_each_sched_entity(se) { // for_each_sched_entity(se)是一个宏定义for (; se; se = se->parent)，顺着se的parent链表往上走。更新子调度实体的同时必须更新父调度实体
cfs_rq = cfs_rq_of(se); // 获取se所属的cfs_rq；
entity_tick(cfs_rq, se, queued); // 完成周期性调度
}
}
entity_tick的函数实现可以参考前面的文章。
entity_tick()函数继续调用check_preempt_tick()函数，这部分在之前的文章已经说过了。check_preempt_tick()函数会根据满足抢占当前进程的条件下设置TIF_NEED_RESCHED标志位。满足抢占条件也很简单，只要顺着se->parent这条链表便利下去，如果有一个se运行时间超过分配限额时间就需要重新调度。
