Linux 2.6 调度系统分析

Linux 的市场非常广阔，从桌面工作站到低端服务器，它都是任何商用操作系统的有力竞争对手。目前，Linux 正全力进军嵌入式系统和高端服务器系统领域，但它的技术缺陷限制了它的竞争力：缺乏对实时任务的支持，多处理机可扩展性差。在 2.4 内核中，造成这两个弱项的关键原因之一就是调度器设计上的缺陷。

2.6 调度系统从设计之初就把开发重点放在更好满足实时性和多处理机并行性上，并且基本实现了它的设计目标。主要设计者，传奇式人物 Ingo Molnar 将新调度系统的特性概括为如下几点：

• 继承和发扬 2.4 版调度器的特点：
  • 交互式作业优先
  • 轻载条件下调度/唤醒的高性能
  • 公平共享
  • 基于优先级调度
  • 高 CPU 使用率
  • SMP 高效亲和
  • 实时调度和 cpu 绑定等调度手段
• 在此基础之上的新特性：
  • O(1)调度算法，调度器开销恒定（与当前系统负载无关），实时性能更好
  • 高可扩展性，锁粒度大幅度减小
  • 新设计的 SMP 亲和方法
  • 优化计算密集型的批处理作业的调度
  • 重载条件下调度器工作更平滑
  • 子进程先于父进程运行等其他改进

在 2.5.x 的试验版本中，新的调度器的开发一直受到广泛关注，实测证明它的确使系统性能得到很大改善。本文就从新设计的数据结构开始，围绕 2.6 对于 2.4 所作的改进，对 2.6 调度系统的原理和实现细节进行分析。2.6 调度器设计相当复杂，文中还存在很多需要继续研究的地方，特别是各个调度参数的设定，随着核心版本的升级，可能还会继续修正。

我们知道，在 2.4 内核中，就绪进程队列是一个全局数据结构，调度器对它的所有操作都会因全局自旋锁而导致系统各个处理机之间的等待，使得就绪队列成为一个明显的瓶颈。

2.4 的就绪队列是一个简单的以 runqueue_head 为头的双向链表，在 2.6 中，就绪队列定义为一个复杂得多的数据结构 struct runqueue，并且，尤为关键的是，每一个 CPU 都将维护一个自己的就绪队列，--这将大大减小竞争。

O(1)算法中很多关键技术都与 runqueue 有关，所以，我们对调度器的分析就先从 runqueue 结构开始。

1) prio_array_t *active, *expired, arrays[2]

runqueue 中最关键的数据结构。每个 CPU 的就绪队列按时间片是否用完分为两部分，分别通过 active 指针和 expired 指针访问，active 指向时间片没用完、当前可被调度的就绪进程，expired 指向时间片已用完的就绪进程。每一类就绪进程都用一个 struct prio_array 的结构表示：

struct prio_array {
		int nr_active;		/* 本进程组中的进程数 */
		struct list_head queue[MAX_PRIO];
							/* 以优先级为索引的 HASH 表，见下 */
		unsigned long bitmap[BITMAP_SIZE];
							/* 加速以上 HASH 表访问的位图，见下 */
};