Linux 2.4调度系统分析--转

发布时间：2021-01-24 12:12:15 所属栏目：Linux 来源：网络整理

导读：副标题#e# 简介：?本文详尽地分析了Linux 2.4内核中调度系统的工作原理，特别是i386体系结构下SMP系统的调度表现。通过对2.4调度系统实现原理及其细节的分析，文章在文末指出了2.4调度系统在功能上、实时性上以及多处理机系统表现上存在的不足，为后继的2.6

如上所述，时钟中断将不断对当前运行的非IDLE进程进行时间片剩余值减1的操作，直至所有就绪队列中的counter都减为0了，就在schedule()中对每个进程（包括休眠进程）利用上述公式执行时间片的更新。其中在[include/asm-i386/param.h]中定义了HZ为100，而counter通常初值为0，nice缺省为0（nice在-20到19之间选择），所以，i386下counter的缺省值为6，也就是大约60ms（时钟中断大约每10ms一次）。

同时，对于休眠的进程而言，其参与计算的counter非0，因此实际上它的counter是在累加，构成一个等比数列COUNTER=COUNTER/2+k，1

因为就绪进程选取算法中counter的值占很大比重（见"就绪进程选择算法"），因此，这种对于休眠进程时间片叠加的做法体现了Linux倾向于优先执行休眠次数比较多，也就是IO密集（IO-bound）的进程。

Linux设计者最初是希望因此而提高交互式进程的响应速度，从而方便终端用户，但IO密集的进程并不一定就是交互式进程，例如数据库操作需要频繁地读写磁盘，从而经常处于休眠状态，动态优先级通常较高，但这种应用并不需要用户交互，所以它反而影响了真正的交互动作的响应。

时间片的长度对系统性能影响也很大。如果太短，进程切换就会过于频繁，开销很大；如果太长，系统响应就会太慢，Linux的策略是在系统响应不至于太慢的前提下让时间片尽可能地长。

从上面的分析我们可以看到，schedule()是进行进程切换的唯一入口，而它的运行时机很特殊。一旦控制进入核心态，就没有任何办法可以打断它，除非自己放弃cpu。一个最典型的例子就是核心线程中如果出现死循环（只要循环中不调用schedule()），系统就会失去响应，此时各种中断（包括时钟中断）仍然在响应，但却不会发生调度，其他进程（包括核心进程）都没有机会运行。

下面给出的是中断返回的代码：

这是此时唯一可能调用schedule()的地方（通过ret_from_sys_call，见"调度器工作时机"），但普通的核心线程不属于任何一种要求的状态，它能响应中断，但不能导致调度。

这个特点的表现之一就是，高优先级的进程无法打断正在核内执行系统调用（或者中断服务）的低优先级进程，这对于实时系统来说是致命的，但却简化了核心代码。内核中很多地方都利用了这一特点，能够不做过多保护地访问共享数据，而不用担心其他进程的打扰。

Linux 2.4通过就绪进程选择算法的设计区分实时进程和非实时进程，只要有实时进程可运行，非实时进程就不会获得运行机会。Linux又将实时进程分为SCHED_RR和SCHED_FIFO两类。SCHED_RR时间片结束后会发生调度，并将自己置于就绪队列的末尾，从而给其他rt_priority相同（或更高）的实时进程运行机会（见"调度器工作流程"），而SCHED_FIFO不会因时间片结束而放弃CPU（见"调度器工作时机"），或者出现更高优先级的实时进程，或者主动放弃CPU，否则SCHED_FIFO将运行到进程结束。

尽管Linux 2.4中区分了实时进程和非实时进程的调度优先权，但也仅此而已。不支持核心抢占运行的操作系统很难实现真正的实时性，因为实时任务的响应时间无法预测。有两种办法使系统的实时性更好，一种是采用设置类似抢占调度点的做法，一种就是使内核真正具备可抢占性。

即使是内核可抢占的系统，也并不一定满足实时性要求，它仅仅解决了CPU资源的访问优先权问题，其他资源也同样需要"被抢占"，例如实时进程应该能够从握有某个共享资源的普通进程手中夺得它所需要的资源，它使用完后再还给普通进程。但实际上，很多系统都无法做到这一点，Linux的调度器更是不具备这种能力。

Linux的调度器原本是针对单处理机系统设计的，在内核发展过程中，不断通过补丁来提高多处理机系统（主要是SMP系统）的执行效率。这种开发方式一直持续到2.4版本，因此在2.4内核中，SMP应用仍然有很多无法突破的障碍，例如全局共享的就绪队列。很多研究团体都在针对Linux调度器的多处理机扩展性作研究，参考文献中列举了其中两个[5][6]，但最权威的改进还是在2.6内核中。

对于超线程CPU，Linux调度器的支持有限，它可以区分同一物理CPU上的两个逻辑CPU，在两个逻辑CPU都空闲的时候，调度器可以优先考虑将进程调度到其中一个逻辑CPU上运行（见"调度器工作流程"）。从原理上说，超线程CPU是存在两个（或多个）执行现场的单CPU，只有两个使用CPU不同部件（比如定点部件和浮点部件）的线程在其上运行的时候才有正的加速，否则，由于执行部件冲突以及Cache miss，使用超线程技术甚至会带来一定程度上的性能损失。Linux 2.4的调度器并不能区分哪些进程是"类似"的，哪些进程会使用不同的执行部件，因此，实际上无法恰当使用超线程CPU。对于其他更复杂的多处理机系统，例如目前高端系统中占统治地位的NUMA结构机器，Linux在调度器上基本未作考虑。例如进程（线程）总优先在创建它的CPU上运行（见"其他核心应用的调度相关部分"之"进程创建"），并倾向于保持在该CPU上（见"就绪进程选择算法"），整个CPU选择过程没有做任何局部性优化。

（编辑：应用网_丽江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!

11/13

首页

尾页