完全公平调度CFS
CFS（Completely Fair Scheduler）试图按照对 CPU 时间的 “最大需求（gravest need）” 运行任务；这有助于确保每个进程可以获得对 CPU 的公平共享。
CFS初探
CFS 调度程序使用安抚（appeasement）策略确保公平性。当某个任务进入运行队列后，将记录当前时间，当某个进程等待 CPU 时，将对这个进程的 wait_runtime 值加一个数，这个数取决于运行队列当前的进程数。当执行这些计算时，也将考虑不同任务的优先级值。 将这个任务调度到 CPU 后，它的 wait_runtime 值开始递减，当这个值递减到其他任务成为红黑树的最左侧任务时，当前任务将被抢占。通过这种方式，CFS 努力实现一种理想 状态，即 wait_runtime 值为 0！
CFS 维护任务运行时（相对于运行队列级时钟，称为 fair_clock(cfs_rq->fair_clock)），它在某个实际时间的片段内运行，因此，对于单个任务可以按照理想的速度运行。
例如，如果具有 4 个可运行的任务，那么 fair_clock 将按照实际时间速度的四分之一增加。每个任务将设法跟上这个速度。这是由分时多任务处理的量子化特性决定的。也就是说，在任何一个时间段内只有一个任务可以运行；因此， 其他进程在时间上的拖欠将增大（wait_runtime）。因此，一旦某个任务进入调度，它将努力赶上它所欠下的时间（并且要比所欠时间多一点，因为在追赶时间期间，fair_clock 不会停止计时）。
粒度和延迟如何关联？
关联粒度和延迟的简单等式为：
gran = (lat/nr) - (lat/nr/nr)
其中 gran = 粒度，
lat = 延迟，而
nr = 运行中的任务数。
加权任务引入了优先级。假设我们有两个任务：其中一个任务占用 CPU 的时间量是另一个任务的两倍，比例为 2:1。执行数学转换后，对于权重为 0.5 的任务，时间流逝的速度是以前的两倍。我们根据 fair_clock 对树进行排队。
请注意，CFS 没有使用时间片（time slices），至少，没有优先使用。CFS 中的时间片具有可变的长度并且动态确定。
运行时调优选项
引入了重要的 sysctls 来在运行时对调度程序进行调优（以 ns 结尾的名称以纳秒为单位）：
sched_latency_ns：针对 CPU 密集型任务进行目标抢占延迟（Targeted preemption latency）。
sched_batch_wakeup_granularity_ns：针对 SCHED_BATCH 的唤醒（Wake-up）粒度。
sched_wakeup_granularity_ns：针对 SCHED_OTHER 的唤醒粒度。
sched_compat_yield：由于 CFS 进行了改动，严重依赖 sched_yield() 的行为的应用程序可以要求不同的性能，因此推荐启用 sysctls。
sched_child_runs_first：child 在 fork 之后进行调度；此为默认设置。如果设置为 0，那么先调度 parent。
sched_min_granularity_ns：针对 CPU 密集型任务执行最低级别抢占粒度。
sched_features：包含各种与调试相关的特性的信息。
sched_stat_granularity_ns：收集调度程序统计信息的粒度。
新的调度程序调试接口
新调度程序附带了一个非常棒的调试接口，还提供了运行时统计信息，分别在 kernel/sched_debug.c 和 kernel/sched_stats.h 中实现。要提供调度程序的运行时信息和调试信息，需要将一些文件添加到 proc pseudo 文件系统：
/proc/sched_debug：显示运行时调度程序可调优选项的当前值、CFS 统计信息和所有可用 CPU 的运行队列信息。当读取这个 proc 文件时，将调用 sched_debug_show() 函数并在 sched_debug.c 中定义。
/proc/schedstat：为所有相关的 CPU 显示特定于运行队列的统计信息以及 SMP 系统中特定于域的统计信息。kernel/sched_stats.h 中定义的 show_schedstat() 函数将处理 proc 条目中的读操作。
/proc/[PID]/sched：显示与相关调度实体有关的信息。在读取这个文件时，将调用 kernel/sched_debug.c 中定义的 proc_sched_show_task() 函数
CFS内部原理
Linux 内的所有任务都由称为 task_struct 的任务结构表示。该结构（以及其他相关内容）完整地描述了任务并包括了任务的当前状态、其堆栈、进程标识、优先级（静态和动态）等等。可以在 ./linux/include/linux/sched.h 中找到这些内容以及相关结构。 但是因为不是所有任务都是可运行的，在 task_struct 中不会发现任何与 CFS 相关的字段。 相反，会创建一个名为 sched_entity 的新结构来跟踪调度信息。
树的根通过 rb_root 元素通过 cfs_rq 结构（在 ./kernel/sched.c 中）引用。红黑树的叶子不包含信息，但是内部节点代表一个或多个可运行的任务。红黑树的每个节点都由 rb_node 表示，它只包含子引用和父对象的颜色。 rb_node 包含在 sched_entity 结构中，该结构包含rb_node引用、负载权重以及各种统计数据。最重要的是，sched_entity 包含 vruntime（64 位字段），它表示任务运行的时间量，并作为红黑树的索引。 最后，task_struct 位于顶端，它完整地描述任务并包含 sched_entity 结构。
就 CFS 部分而言，调度函数非常简单。 在 ./kernel/sched.c 中，通用 schedule() 函数，它会先抢占当前运行任务（除非它通过 yield() 代码先抢占自己）。注意 CFS 没有真正的时间切片概念用于抢占，因为抢占时间是可变的。当前运行任务（现在被抢占的任务）通过对 put_prev_task 调用（通过调度类）返回到红黑树。当schedule函数开始确定下一个要调度的任务时，它会调用 pick_next_task函数。此函数也是通用的（在./kernel/sched.c 中），但它会通过调度器类调用 CFS 调度器。
CFS调度算法的核心是选择具有最小vruntine的任务。运行队列采用红黑树方式存放，其中节点的键值便是可运行进程的虚拟运行时间。CFS调度器选取待运行的下一个进程，是所有进程中vruntime最小的那个，他对应的便是在树中最左侧的叶子节点。实现选择的函数为pick_next_task_fair，CFS 中的 pick_next_task 函数可以在 ./kernel/sched_fair.c（称为pick_next_task_fair()）中找到。 此函数只是从红黑树中获取最左端的任务并返回相关sched_entity。通过此引用，一个简单的 task_of()调用确定返回的task_struct 引用。通用调度器最后为此任务提供处理器。
static struct task_struct *pick_next_task_fair(struct rq *rq)
{
struct task_struct *p;
struct cfs_rq *cfs_rq = &rq->cfs;
struct sched_entity *se;
if (unlikely(!cfs_rq->nr_running))
return NULL;
do {/*此循环为了考虑组调度*/
se = pick_next_entity(cfs_rq);
set_next_entity(cfs_rq, se);/*设置为当前运行进程*/
cfs_rq = group_cfs_rq(se);
} while (cfs_rq);
p = task_of(se);
hrtick_start_fair(rq, p);
return p;
}
实质工作调用__pick_next_entity完成。
/*函数本身并不会遍历数找到最左叶子节点(即就是所有进程中vruntime最小的那个),因为该值已经缓存在rb_leftmost字段中*/
static struct sched_entity *__pick_next_entity(struct cfs_rq *cfs_rq)
{
/*rb_leftmost为保存的红黑树的最左边的节点*/
struct rb_node *left = cfs_rq->rb_leftmost;
if (!left)
return NULL;
return rb_entry(left, struct sched_entity, run_node);
}
重要的 CFS 数据结构
对于每个 CPU，CFS 使用按时间排序的红黑（red-black）树。
红黑树是一种自平衡二叉搜索树，这种数据结构可用于实现关联数组。对于每个运行中的进程，在红黑树上都有一个节点。红黑树上位于最左侧的进程表示将进行下一次调度的进程。红黑树比较复杂，但它的操作具有良好的最差情况（worst-case）运行时，并且在实际操作中非常高效：它可以在 O(log n) 时间内搜索、插入和删除 ，其中 n 表示树元素的数量。叶节点意义不大并且不包含数据。为节省内存，有时使用单个哨兵（sentinel）节点执行所有叶节点的角色。内部节点到叶节点的所有引用都指向哨兵节点。
该树方法能够良好运行的原因在于：
1.红黑树可以始终保持平衡。
2.由于红黑树是二叉树，查找操作的时间复杂度为对数。但是，除了最左侧查找以外，很难执行其他查找，并且最左侧的节点指针始终被缓存。
3.对于大多数操作，红黑树的执行时间为 O(log n)，而以前的调度程序通过具有固定优先级的优先级数组使用 O(1)。O(log n) 行为具有可测量的延迟，但是对于较大的任务数无关紧要。Molnar 在尝试这种树方法时，首先对这一点进行了测试。
4.红黑树可通过内部存储实现 — 即不需要使用外部分配即可对数据结构进行维护。
让我们了解一下实现这种新调度程序的一些关键数据结构。
struct task_struct 的变化
CFS 去掉了 struct prio_array，并引入调度实体（scheduling entity）和调度类 （scheduling classes），分别由 struct sched_entity 和 struct sched_class 定义。因此，task_struct 包含关于 sched_entity 和 sched_class 这两种结构的信息：
struct task_struct {
/* Defined in 2.6.23:/usr/include/linux/sched.h */....
- struct prio_array *array;
+ struct sched_entity se;
+ struct sched_class *sched_class;
.... ....
};
struct sched_entity
运行实体结构为sched_entity，该结构包含了完整的信息，用于实现对单个任务或任务组的调度。它可用于实现组调度。调度实体可能与进程没有关联。所有的调度器都必须对进程运行时间做记账。CFS不再有时间片的概念，但是他也必须维护每个进程运行的时间记账，因为他需要确保每个进程只在公平分配给他的处理器时间内运行。CFS使用调度器实体结构来最终运行记账。
实现记账功能，由系统定时器周期调用
static void update_curr(struct cfs_rq *cfs_rq)
{
struct sched_entity *curr = cfs_rq->curr;
u64 now = rq_of(cfs_rq)->clock;/*now计时器*/
unsigned long delta_exec;
if (unlikely(!curr))
return;
/*
* Get the amount of time the current task was running
* since the last time we changed load (this cannot
* overflow on 32 bits):
*/
/*获得从最后一次修改负载后当前任务所占用的运行总时间*/
/*即计算当前进程的执行时间*/
delta_exec = (unsigned long)(now - curr->exec_start);
if (!delta_exec)/*如果本次没有执行过，不用重新更新了*/
return;
/*根据当前可运行进程总数对运行时间进行加权计算*/
__update_curr(cfs_rq, curr, delta_exec);
curr->exec_start = now;/*将exec_start属性置为now*/
if (entity_is_task(curr)) {/*下面为关于组调度的，暂时不分析了*/
struct task_struct *curtask = task_of(curr);
trace_sched_stat_runtime(curtask, delta_exec, curr->vruntime);
cpuacct_charge(curtask, delta_exec);
account_group_exec_runtime(curtask, delta_exec);
}
}
struct sched_class
该调度类类似于一个模块链，协助内核调度程序工作。每个调度程序模块需要实现 struct sched_class建议的一组函数。
函数功能说明：
enqueue_task：当某个任务进入可运行状态时，该函数将得到调用。它将调度实体（进程）放入红黑树中，并对 nr_running 变量加 1。
dequeue_task：当某个任务退出可运行状态时调用该函数，它将从红黑树中去掉对应的调度实体，并从 nr_running 变量中减 1。
yield_task：在 compat_yield sysctl 关闭的情况下，该函数实际上执行先出队后入队；在这种情况下，它将调度实体放在红黑树的最右端。
check_preempt_curr：该函数将检查当前运行的任务是否被抢占。在实际抢占正在运行的任务之前，CFS 调度程序模块将执行公平性测试。这将驱动唤醒式（wakeup）抢占。
pick_next_task：该函数选择接下来要运行的最合适的进程。
load_balance：每个调度程序模块实现两个函数，load_balance_start() 和load_balance_next()，使用这两个函数实现一个迭代器，在模块的 load_balance 例程中调用。内核调度程序使用这种方法实现由调度模块管理的进程的负载平衡。
set_curr_task：当任务修改其调度类或修改其任务组时，将调用这个函数。
task_tick：该函数通常调用自 time tick 函数；它可能引起进程切换。这将驱动运行时（running）抢占。
task_new：内核调度程序为调度模块提供了管理新任务启动的机会。CFS 调度模块使用它进行组调度，而用于实时任务的调度模块则不会使用这个函数。
运行队列中CFS 有关的字段
对于每个运行队列，都提供了一种结构来保存相关红黑树的信息。
struct cfs_rq {
struct load_weight load;/*运行负载*/
unsigned long nr_running;/*运行进程个数*/
u64 exec_clock;
u64 min_vruntime;/*保存的最小运行时间*/
struct rb_root tasks_timeline;/*运行队列树根*/
struct rb_node *rb_leftmost;/*保存的红黑树最左边的
节点，这个为最小运行时间的节点，当进程
选择下一个来运行时，直接选择这个*/
struct list_head tasks;
struct list_head *balance_iterator;
/*
* 'curr' points to currently running entity on this cfs_rq.
* It is set to NULL otherwise (i.e when none are currently running).
*/
struct sched_entity *curr, *next, *last;
unsigned int nr_spread_over;
#ifdef CONFIG_FAIR_GROUP_SCHED
struct rq *rq; /* cpu runqueue to which this cfs_rq is attached */
/*
* leaf cfs_rqs are those that hold tasks (lowest schedulable entity in
* a hierarchy). Non-leaf lrqs hold other higher schedulable entities
* (like users, containers etc.)
*
* leaf_cfs_rq_list ties together list of leaf cfs_rq's in a cpu. This
* list is used during load balance.
*/
struct list_head leaf_cfs_rq_list;
struct task_group *tg; /* group that "owns" this runqueue */
#ifdef CONFIG_SMP
/*
* the part of load.weight contributed by tasks
*/
unsigned long task_weight;
/*
* h_load = weight * f(tg)
*
* Where f(tg) is the recursive weight fraction assigned to
* this group.
*/
unsigned long h_load;
/*
* this cpu's part of tg->shares
*/
unsigned long shares;
/*
* load.weight at the time we set shares
*/
unsigned long rq_weight;
#endif
#endif
};
内核 2.6.24 中的变化
新版本中不再追赶全局时钟（fair_clock），任务之间将彼此追赶。将引入每个任务（调度实体）的时钟 vruntime（wall_time/task_weight），并且将使用近似的平均时间初始化新任务的时钟。其他重要改动将影响关键数据结构。下面展示了 struct sched_entity 中的预期变动：
每个任务都跟踪它的运行时，并根据该值对任务进行排队。这意味着运行最少的任务将位于树的最左侧。同样，通过对时间加权划分优先级。每个任务在下面的时间段内力求获得精确调度：
sched_period = (nr_running > sched_nr_latency) ? sysctl_sched_latency : ((nr_running * sysctl_sched_latency) / sched_nr_latency)
其中 sched_nr_latency = (sysctl_sched_latency / sysctl_sched_min_granularity)。这表示，当可运行任务数大于 latency_nr 时，将线性延长调度周期。sched_fair.c 中定义的 sched_slice() 是进行这些计算的位置。因此，如果每个可运行任务运行与 sched_slice() 等价的时间，那么将花费的时间为 sched_period，每个任务将运行与其权重成比例的时间量。此外，在任何时刻，CFS 都承诺超前运行 sched_period，因为最后执行调度的任务将在这个时限内再次运行。
因此，当一个新任务变为可运行状态时，对其位置有严格的要求。在所有其他任务运行之前，此任务不能运行；否则，将破坏对这些任务作出的承诺。然而，由于该任务确实进行了排队，对运行队列的额外权重将缩短其他所有任务的时间片，在 sched_priod 的末尾释放一点位置，刚好满足新任务的需求。这个新的任务就被放在这个位置。
优先级和CFS
CFS 不直接使用优先级而是将其用作允许任务执行的时间的衰减系数。 低优先级任务具有更高的衰减系数，而高优先级任务具有较低的衰减系数。 这意味着与高优先级任务相比，低优先级任务允许任务执行的时间消耗得更快。 这是一个绝妙的解决方案，可以避免维护按优先级调度的运行队列。
CFS 组调度
考虑一个两用户示例，用户 A 和用户 B 在一台机器上运行作业。用户 A 只有两个作业正在运行，而用户 B 正在运行 48 个作业。组调度使 CFS 能够对用户 A 和用户 B 进行公平调度，而不是对系统中运行的 50 个作业进行公平调度。每个用户各拥有 50% 的 CPU 使用。用户 B 使用自己 50% 的 CPU 分配运行他的 48 个作业，而不会占用属于用户 A 的另外 50% 的 CPU 分配。
CFS 调度模块（在 kernel/sched_fair.c 中实现）用于以下调度策略：SCHED_NORMAL、SCHED_BATCH 和 SCHED_IDLE。对于 SCHED_RR 和 SCHED_FIFO 策略，将使用实时调度模块（该模块在 kernel/sched_rt.c 中实现）。
CFS 另一个有趣的地方是组调度 概念（在 2.6.24 内核中引入）。组调度是另一种为调度带来公平性的方式，尤其是在处理产生很多其他任务的任务时。 假设一个产生了很多任务的服务器要并行化进入的连接（HTTP服务器的典型架构）。不是所有任务都会被统一公平对待，CFS 引入了组来处理这种行为。产生任务的服务器进程在整个组中（在一个层次结构中）共享它们的虚拟运行时，而单个任务维持其自己独立的虚拟运行时。这样单个任务会收到与组大致相同的调度时间。我们会发现 /proc 接口用于管理进程层次结构，让我们对组的形成方式有完全的控制。使用此配置，我们可以跨用户、跨进程或其变体分配公平性。
调度类和域
与 CFS 一起引入的是调度类概念。每个任务都属于一个调度类，这决定了任务将如何调度。 调度类定义一个通用函数集（通过sched_class），函数集定义调度器的行为。例如，每个调度器提供一种方式， 添加要调度的任务、调出要运行的下一个任务、提供给调度器等等。每个调度器类都在一对一连接的列表中彼此相连，使类可以迭代（例如，要启用给定处理器的禁用）。一般结构如下图所示。注意，将任务函数加入队列或脱离队列只需从特定调度结构中加入或移除任务。 函数 pick_next_task 选择要执行的下一个任务（取决于调度类的具体策略）。
但是不要忘了调度类是任务结构本身的一部分，这一点简化了任务的操作，无论其调度类具体如何实现。例如， 以下函数用 ./kernel/sched.c 中的新任务抢占当前运行任务（其中 curr 定义了当前运行任务， rq 代表 CFS 红黑树而 p 是下一个要调度的任务）：
static inline void check_preempt( struct rq *rq, struct task_struct *p ){
rq->curr->sched_class->check_preempt_curr( rq, p );
}
如果此任务正使用公平调度类，则 check_preempt_curr() 将解析为check_preempt_wakeup()。 我们可以在 ./kernel/sched_rt.c,/kernel/sched_fair.c 和 ./kernel/sched_idle.c 中查看这些关系。
调度类是调度发生变化的另一个有趣的地方，但是随着调度域的增加，功能也在增加。 这些域允许您出于负载平衡和隔离的目的将一个或多个处理器按层次关系分组。 一个或多个处理器能够共享调度策略（并在其之间保持负载平衡）或实现独立的调度策略从而故意隔离任务。
2.6.24 中的组调度有哪些改变
在 2.6.24 中，我们将能够对调度程序进行调优，从而实现对用户或组的公平性，而不是任务公平性。可以将任务进行分组，形成多个实体，调度程序将平等对待这些实体，继而公平对待实体中的任务。要启用这个特性，在编译内核时需要选择 CONFIG_FAIR_GROUP_SCHED。目前，只有 SCHED_NORMAL 和SCHED_BATCH 任务可以进行分组。
可以使用两个独立的方法对任务进行分组，它们分别基于：
1.用户 ID。
2.cgroup pseudo 文件系统：这个选项使管理员可以根据需要创建组。有关更多细节，阅读内核源文档目录中的 cgroups.txt 文件。
3.内核配置参数 CONFIG_FAIR_USER_SCHED 和 CONFIG_FAIR_CGROUP_SCHED 可帮助您进行选择。
通过引入调度类并通过增强调度统计信息来简化调试，这个新的调度程序进一步扩展了调度功能。
其他调度器
继续研究调度，您将发现正在开发中的调度器将会突破性能和扩展性的界限。Con Kolivas 没有被他的 Linux 经验羁绊，他开发出了另一个 Linux 调度器，其缩写为：BFS。该调度器据说在 NUMA 系统以及移动设备上具有更好的性能， 并且被引入了 Android 操作系统的一款衍生产品中。
展望
对于 Linux 技术而言，惟一不变的就是永恒的变化。今天，CFS 是 2.6 Linux 调度器； 明天可能就会是另一个新的调度器或一套可以被静态或动态调用的调度器。 CFS、RSDL 以及内核背后的进程中还有很多秘密等待我们去研究。
