linux内核-进程调度浅析

转自：http://hi.baidu.com/_kouu/item/38c81042455c97d2c1a592d9

      首先，我们需要明确一点：进程调度是对TASK_RUNNING状态的进程进行调度（参见《linux进程状态浅析》）。如果进程不可执行（正在睡眠或其他），那么它跟进程调度没多大关系。所以，如果你的系统负载非常低，盼星星盼月亮才出现一个可执行状态的进程。那么进程调度也就不会太重要。哪个进程可执行，就让它执行去，没有什么需要多考虑的。

      反之，如果系统负载非常高，时时刻刻都有N多个进程处于可执行状态，等待被调度运行。那么进程调度程序为了协调这N个进程的执行，必定得做很多工作。协调得不好，系统的性能就会大打折扣。这个时候，进程调度就是非常重要的。

      尽管我们平常接触的很多计算机（如桌面系统、网络服务器、等）负载都比较低，但是linux作为一个通用操作系   统，不能假设系统负载低，必须为应付高负载下的进程调度做精心的设计。

      当然，这些设计对于低负载（且没有什么实时性要求）的环境，没多大用。极端情况下，如果CPU的负载始终保持0或1（永远都只有一个进程或没有进程需要在CPU上运行），那么这些设计基本上都是徒劳的。

优先级
     现在的操作系统为了协调多个进程的“同时”运行，最基本的手段就是给进程定义优先级。定义了进程的优先级，如果有多个进程同时处于可执行状态，那么谁优先级高谁就去执行，没有什么好纠结的了。那么，进程的优先级该如何确定呢？有两种方式：由用户程序指定、由内核的调度程序动态调整。

     linux内核将进程分成两个级别：普通进程和实时进程。实时进程的优先级都高于普通进程，除此之外，它们的调度策略也有所不同。

实时进程的调度
     实时，原本的涵义是“给定的操作一定要在确定的时间内完成”。重点并不在于操作一定要处理得多快，而是时间要可控（在最坏情况下也不能突破给定的时间）。这样的“实时”称为“硬实时”，多用于很精密的系统之中（比如什么火箭、导弹之类的）。一般来说，硬实时的系统是相对比较专用的。

     像linux这样的通用操作系统显然没法满足这样的要求，中断处理、虚拟内存、等机制的存在给处理时间带来了很大的不确定性。硬件的cache、磁盘寻道、总线争用、也会带来不确定性。
比如考虑“i++;”这么一句C代码。绝大多数情况下，它执行得很快。但是极端情况下还是有这样的可能：
     1、i的内存空间未分配，CPU触发缺页异常。而linux在缺页异常的处理代码中试图分配内存时，又可能由于系统内存紧缺而分配失败，导致进程进入睡眠；
     2、代码执行过程中硬件产生中断，linux进入中断处理程序而搁置当前进程。而中断处理程序的处理过程中又可能发生新的硬件中断，中断永远嵌套不止……；
等等……
而像linux这样号称实现了“实时”的通用操作系统，其实只是实现了“软实时”，即尽可能地满足进程的实时需求。

     如果一个进程有实时需求（它是一个实时进程），则只要它是可执行状态的，内核就一直让它执行，以尽可能地满足它对CPU的需要，直到它完成所需要做的事情，然后睡眠或退出（变为非可执行状态）。
而如果有多个实时进程都处于可执行状态，则内核会先满足优先级最高的实时进程对CPU的需要，直到它变为非可执行状态。
     于是，只要高优先级的实时进程一直处于可执行状态，低优先级的实时进程就一直不能得到CPU；只要一直有实时进程处于可执行状态，普通进程就一直不能得到CPU。
（后来，内核添加了/proc/sys/kernel/sched_rt_runtime_us和/proc/sys/kernel/sched_rt_period_us两个参数，限定了在以sched_rt_period_us为周期的时间内，实时进程最多只能运行sched_rt_runtime_us这么多时间。这样就在一直有实时进程处于可执行状态的情况下，给普通进程留了一点点能够得到执行的机会。参阅《linux组调度浅析》。）

     那么，如果多个相同优先级的实时进程都处于可执行状态呢？这时就有两种调度策略可供选择：
     1、SCHED_FIFO：先进先出。直到先被执行的进程变为非可执行状态，后来的进程才被调度执行。在这种策略下，先来的进程可以执行sched_yield系统调用，自愿放弃CPU，以让权给后来的进程；
     2、SCHED_RR：轮转调度。内核为实时进程分配时间片，在时间片用完时，让下一个进程使用CPU；
强调一下，这两种调度策略仅仅针对于相同优先级的多个实时进程同时处于可执行状态的情况。

      在linux下，用户程序可以通过sched_setscheduler系统调用来设置进程的调度策略以及相关调度参数；sched_setparam系统调用则只用于设置调度参数。这两个系统调用要求用户进程具有设置进程优先级的能力（CAP_SYS_NICE，一般来说需要root权限）（参阅capability相关的文章）。
通过将进程的策略设为SCHED_FIFO或SCHED_RR，使得进程变为实时进程。而进程的优先级则是通过以上两个系统调用在设置调度参数时指定的。

      对于实时进程，内核不会试图调整其优先级。因为进程实时与否？有多实时？这些问题都是跟用户程序的应用场景相关，只有用户能够回答，内核不能臆断。

      综上所述，实时进程的调度是非常简单的。进程的优先级和调度策略都由用户定死了，内核只需要总是选择优先级最高的实时进程来调度执行即可。唯一稍微麻烦一点的只是在选择具有相同优先级的实时进程时，要考虑两种调度策略。


普通进程的调度
      实时进程调度的中心思想是，让处于可执行状态的最高优先级的实时进程尽可能地占有CPU，因为它有实时需求；而普通进程则被认为是没有实时需求的进程，于是调度程序力图让各个处于可执行状态的普通进程和平共处地分享CPU，从而让用户觉得这些进程是同时运行的。
与实时进程相比，普通进程的调度要复杂得多。内核需要考虑两件麻烦事：

一、动态调整进程的优先级
     按进程的行为特征，可以将进程分为“交互式进程”和“批处理进程”：
交互式进程（如桌面程序、服务器、等）主要的任务是与外界交互。这样的进程应该具有较高的优先级，它们总是睡眠等待外界的输入。而在输入到来，内核将其唤醒时，它们又应该很快被调度执行，以做出响应。比如一个桌面程序，如果鼠标点击后半秒种还没反应，用户就会感觉系统“卡”了；
批处理进程（如编译程序）主要的任务是做持续的运算，因而它们会持续处于可执行状态。这样的进程一般不需要高优先级，比如编译程序多运行了几秒种，用户多半不会太在意；

     如果用户能够明确知道进程应该有怎样的优先级，可以通过nice、setpriority系统调用来对优先级进行设置。（如果要提高进程的优先级，要求用户进程具有CAP_SYS_NICE能力。）
然而应用程序未必就像桌面程序、编译程序这样典型。程序的行为可能五花八门，可能一会儿像交互式进程，一会儿又像批处理进程。以致于用户难以给它设置一个合适的优先级。
再者，即使用户明确知道一个进程是交互式还是批处理，也多半碍于权限或因为偷懒而不去设置进程的优先级。（你又是否为某个程序设置过优先级呢？）
于是，最终，区分交互式进程和批处理进程的重任就落到了内核的调度程序上。

调度程序关注进程近一段时间内的表现（主要是检查其睡眠时间和运行时间），根据一些经验性的公式，判断它现在是交互式的还是批处理的？程度如何？最后决定给它的优先级做一定的调整。
进程的优先级被动态调整后，就出现了两个优先级：
1、用户程序设置的优先级（如果未设置，则使用默认值），称为静态优先级。这是进程优先级的基准，在进程执行的过程中往往是不改变的；
2、优先级动态调整后，实际生效的优先级。这个值是可能时时刻刻都在变化的；

    进程的交互程度由task_struct结构中的sleep_avg和interactive_credit变量表征。当一个进程从睡眠状态唤醒后，内核调用recalc_task_prio() 函数增加它的sleep_avg，直到达到MAX_SLEEP_AVG；而当进程每运行一个时钟tick，sleep_avg会被减小直到零。recalc_task_prio() 函数同时还调整interactive_credit的数值，一旦它达到CREDIT_LIMIT即认为该进程是交互进程。
    动态优先级的计算由effect_prio() 函数完成，它根据进程的static_prio和sleep_avg数值计算出进程的动态优先级，sleep_avg越大，计算出来的优先级就越高。与先前的内核不同，2.6内核中优先级的计算不再集中在调度器选择候选进程的时候进行，只要进程状态发生改变，内核就有可能计算并设置进程的动态优先级。如进程被抢断时，内核在scheduler_tick()函数中调用effect_prio()计算动态优先级。
内核对交互式进程赋予了更高的优先。内核通过TASK_INTERACTIVE()宏判断一个进程是否交互式进程，如果一个进程足够交互，则当它的时间片耗尽后，它将被重新插入active数组，而不象非交互进程那样被插入expired数组，于是这个进程将得到更多的运行机会。为了防止非交互进程被交互进程长时间的阻塞在expired数组中，保证调度策略的公平性，内核在一个进程时间片耗尽时，通过EXPIRED_STARVING()宏判断当前CPU的runqueue中是否有进程在expired队列中等待过长时间。如果有这样的进程，那么即使当前进程是交互进程也不再将其插入active数组，而是排空active数组，切换到expired数组运行。

二、调度的公平性
在支持多进程的系统中，理想情况下，各个进程应该是根据其优先级公平地占有CPU。而不会出现“谁运气好谁占得多”这样的不可控的情况。
linux实现公平调度基本上是两种思路：
1、给处于可执行状态的进程分配时间片（按照优先级），用完时间片的进程被放到“过期队列”中。等可执行状态的进程都过期了，再重新分配时间片；
2、动态调整进程的优先级。随着进程在CPU上运行，其优先级被不断调低，以便其他优先级较低的进程得到运行机会；
后一种方式有更小的调度粒度，并且将“公平性”与“动态调整优先级”两件事情合而为一，大大简化了内核调度程序的代码。因此，这种方式也成为内核调度程序的新宠。

强调一下，以上两点都是仅针对普通进程的。而对于实时进程，内核既不能自作多情地去动态调整优先级，也没有什么公平性可言。

普通进程具体的调度算法非常复杂，并且随linux内核版本的演变也在不断更替（不仅仅是简单的调整），所以本文就不继续深入了。有兴趣的朋友可以参考下面的链接：
《Linux 调度器发展简述》
《鼠眼看Linux调度器》
《鼠眼再看Linux调度器［1］》
《鼠眼再看Linux调度器［2］》

调度程序的效率
“优先级”明确了哪个进程应该被调度执行，而调度程序还必须要关心效率问题。调度程序跟内核中的很多过程一样会频繁被执行，如果效率不济就会浪费很多CPU时间，导致系统性能下降。
在linux 2.4时，可执行状态的进程被挂在一个链表中。每次调度，调度程序需要扫描整个链表，以找出最优的那个进程来运行。复杂度为O(n)；
在linux 2.6早期，可执行状态的进程被挂在N(N=140)个链表中，每一个链表代表一个优先级，系统中支持多少个优先级就有多少个链表。每次调度，调度程序只需要从第一个不为空的链表中取出位于链表头的进程即可。这样就大大提高了调度程序的效率，复杂度为O(1)；
在linux 2.6近期的版本中，可执行状态的进程按照优先级顺序被挂在一个红黑树（可以想象成平衡二叉树）中。每次调度，调度程序需要从树中找出优先级最高的进程。复杂度为O(logN)。

那么，为什么从linux 2.6早期到近期linux 2.6版本，调度程序选择进程时的复杂度反而增加了呢？
这是因为，与此同时，调度程序对公平性的实现从上面提到的第一种思路改变为第二种思路（通过动态调整优先级实现）。而O(1)的算法是基于一组数目不大的链表来实现的，按我的理解，这使得优先级的取值范围很小（区分度很低），不能满足公平性的需求。而使用红黑树则对优先级的取值没有限制（可以用32位、64位、或更多位来表示优先级的值），并且O(logN)的复杂度也还是很高效的。

调度触发的时机
调度的触发主要有如下几种情况：
1、当前进程（正在CPU上运行的进程）状态变为非可执行状态。
进程执行系统调用主动变为非可执行状态。比如执行nanosleep进入睡眠、执行exit退出、等等；
进程请求的资源得不到满足而被迫进入睡眠状态。比如执行read系统调用时，磁盘高速缓存里没有所需要的数据，从而睡眠等待磁盘IO；
进程响应信号而变为非可执行状态。比如响应SIGSTOP进入暂停状态、响应SIGKILL退出、等等；

2、抢占。进程运行时，非预期地被剥夺CPU的使用权。这又分两种情况：进程用完了时间片、或出现了优先级更高的进程。
优先级更高的进程受正在CPU上运行的进程的影响而被唤醒。如发送信号主动唤醒，或因为释放互斥对象（如释放锁）而被唤醒；
内核在响应时钟中断的过程中，发现当前进程的时间片用完；
内核在响应中断的过程中，发现优先级更高的进程所等待的外部资源的变为可用，从而将其唤醒。比如CPU收到网卡中断，内核处理该中断，发现某个socket可读，于是唤醒正在等待读这个socket的进程；再比如内核在处理时钟中断的过程中，触发了定时器，从而唤醒对应的正在nanosleep系统调用中睡眠的进程；

其他问题

1、多处理器下的负载均衡

     如果系统中只有一个可执行队列，哪个CPU空闲了就去队列中找一个最合适的进程来执行。这样不是很好很均衡吗？的确如此，但是多处理器共用一个可执行队列会有一些问题。显然，每个CPU在执行调度程序时都需要把队列锁起来，这会使得调度程序难以并行，可能导致系统性能下降。而如果每个CPU对应一个可执行队列则不存在这样的问题。另外，多个可执行队列还有一个好处。这使得一个进程在一段时间内总是在同一个CPU上执行，那么很可能这个CPU的各级cache中都缓存着这个进程的数据，很有利于系统性能的提升。所以，在linux下，每个CPU都有着对应的可执行队列，而一个可执行状态的进程在同一时刻只能处于一个可执行队列中。
     于是，“多处理器负载均衡”这个麻烦事情就来了。内核需要关注各个CPU可执行队列中的进程数目，在数目不均衡时做出适当调整。什么时候需要调整，以多大力度进程调整，这些都是内核需要关心的。当然，尽量不要调整最好，毕竟调整起来又要耗CPU、又要锁可执行队列，代价还是不小的。
      在多处理器系统中，由于存在多个就绪进程队列runqueue，可能存在多个队列之间负载的不平衡状况：其中一部分runqueue包含的进程远远大于其余runqueue，这种情况将影响系统的整体性能。Linux通过load_balance()函数实现各就绪队列间的负载平衡。该函数在两种情况下被调用：schedule()在当前runqueue为空时调用或者在系统空闲时由定时器调用每1ms调用一次，而在系统忙时则由定时器每200ms调用一次。当load_balance()由schedule()调用时，由于当前runqueue是空的，它简单的寻找任意就绪进程将其加入当前队列；而当由定时器调用时，load_balance()处理的工作相当复杂：

   （1）首先，load_balance()调用find_busiest_queue()确定最繁忙的runqueue，即包含最多就绪进程的队列。
   （2）其次，load_balance()决定从最繁忙runqueue的哪个prio_array数组“拉”出进程。除非该runqueue的expired数组为空，否则load_balance()总是选择expired数组。
   （3）Load_balance()然后从选定的prio_array数组中找到优先级最高的进程列表。接着分析列表中的每个进程以确定是否适合被“拉”出，如果适合，则调用pull_task()将该进程从原runqueue“拉”到当前runqueue。重复此过程直到负载平衡。

2、优先级继承

      由于互斥，一个进程（设为A）可能因为等待进入临界区而睡眠。直到正在占有相应资源的进程（设为B）退出临界区，进程A才被唤醒。可能存在这样的情况：A的优先级非常高，B的优先级非常低。B进入了临界区，但是却被其他优先级较高的进程（设为C）抢占了，而得不到运行，也就无法退出临界区。于是A也就无法被唤醒。

A有着很高的优先级，但是现在却沦落到跟B一起，被优先级并不太高的C抢占，导致执行被推迟。这种现象就叫做优先级反转。出现这种现象是很不合理的。较好的应对措施是：当A开始等待B退出临界区时，B临时得到A的优先级（还是假设A的优先级高于B），以便顺利完成处理过程，退出临界区。之后B的优先级恢复。这就是优先级继承的方法。

      为了实现优先级继承，内核又得做很多事情。更细节的东西可以参考一下关于“优先级反转”或“优先级继承”的文章。

3、中断处理线程化

      在linux下，中断处理程序运行于一个不可调度的上下文中。从CPU响应硬件中断自动跳转到内核设定的中断处理程序去执行，到中断处理程序退出，整个过程是不能被抢占的。一个进程如果被抢占了，可以通过保存在它的进程控制块（task_struct）中的信息，在之后的某个时间恢复它的运行。而中断上下文则没有task_struct，被抢占了就没法恢复了。中断处理程序不能被抢占，也就意味着中断处理程序的“优先级”比任何进程都高（必须等中断处理程序完成了，进程才能被执行）。但是在实际的应用场景中，可能某些实时进程应该得到比中断处理程序更高的优先级。

于是，一些实时性要求更高的系统就给中断处理程序赋予了task_struct以及优先级，使得它们在必要的时候能够被高优先级的进程抢占。但是显然，做这些工作是会给系统造成一定开销的，这也是为了实现“实时”而对性能做出的一种让步。