linux2.4到linux2.6内核调度（1）

本文从 Linux 2.4 调度系统的缺陷入手，详细分析了 Linux 2.6 调度系统的原理和实现细节，并对与调度系统相关的负载平衡、NUMA 结构以及实时性能进行了分析和评价。文末，作者从调度系统的发展和实现出发，对 Linux 的发展特点和方向提出了自己的看法。

1．前言

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．新的数据结构runqueue

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

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

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