• Linux与任何分时系统一样,
• 一个进程到另一个进程的快速切换,
• 多个进程同时执行的神奇效果。
• 进程切换本身已在第三章中讨论过,
• 本章进程调度(schednling),
• 什么时候进行进程切换及选择哪一个进程来运行。

• 三部分组成。
• “调度策略”理论上介绍 Linux进行进程调度所做的选择。
• “调度算法”实现调度所采用的数据结构和相应的算法。
• “与调度相关的系统调用”描述影响进程调度的系统调用

• 为简单,
• 仍以80x86为例;
• 假定系统采用统一内存访问( Uniform Memory Access),
• 且系统时钟设定为1ms。

调度策略

• 传统Unix操作系统的调度算法必须实现几个互相冲突的目标:进程响应时间尽可能快,后台作业的吞吐量尽可能高,尽可能避免进程的饥饿现象,低优先级和高优先级进程的需要尽可能调和等等。
• 决定什么时侯以怎样的方式选择一个新进程运行的这组规则就是
  scheduling policy

• Linux的调度基于time sharing)
• 多个进程以“时间多路复用”方式运行
• CPU的时间被分成“slice”,给每个可运行进程分配一片(注1)
• 单处理器在任何给定的时刻只能运行一进程
• 如果当前运行进程的时间片或时限到期,
  • 进程还没有运行完,
  • 进程切换就发生
• 分时依赖于定时中断,因此对进程透明
• 不需要在程序中插入额外的代码来保证CPU分时

• 调度策略根据进程的优先级对它们分类。
• 有时用复杂算法求出进程当前的优先级,
• 但最后的结果是相同的:
  • 每个进程都与一个值相关联,这个值表示把进程如何适当地分配给CPU

• Linux中,进程优先级是动态的。
• 调度程序跟踪进程正在做什么,并周期性地调整它们优先级。
• 这种方式下,在较长的时间间隔内没有使用CPU的进程,通过动态地
  增加它们的优先级来提升它们。
• 已经在CPU上运行了较长时间的进程,通过减少它们的优先级来处罚它们。

• 谈及调度时,
• 把进程分类为“I/O受限”或“CPU受限”。
• 频繁用IO设备,花多时间等待IO操作完成;
• 需大量CPU时间的数值计算应用程序。

• 另一种分类法把进程区分三类
• 交互式进程
• 花很多时间等待键盘和鼠标
• 当接受输入后,进程须被很快唤醒,
  • 否则用户将发现系统反应迟钝。
  • 平均延迟50~150ms
• 延迟变化也必须进行限制,否则系统是不稳定
• 命令shell、文本编辑程序及图形应用程序。

• 批处理进程( batch process)
• 不必与用户交互,经常后台运行。
• 这样的进程不必被很快响应,
  • 常受到调度程序的慢待。
• 程序设计语言的编译程序
• 数据库搜索引擎及科学计算

• 实时进程
• 很强调度需要。
• 这样的进程不被低优先级进程阻塞,
  • 应有短的响应时间,
  • 响应时间的变化应该很小。
• 典型的实时程序有
  • 视频和音频应用程序、
  • 机器人控制程序及从物理传感器上收集数据的程序。

• 一个批处理进程可能是I/O受限型的(如数据库服务器),或CPU受限型的(如图像绘制程序)。
• Linux中,调度算法可明确地确认所有实时程序的身份,但没有办法区分交互式程序和批处理程序。
• 2.6调度程序实现了基于进程过去行为的启发式算法,以确定进程应该被当作交互式进程还是批处理进程。
• 与批处理进程相比,调度程序有偏爱交互式进程的倾向。
• 通过表7-1所列的系统调用改变调度优先级。
• 更详细在“与调度相关的系统调用”一节中给出。

进程的抢占

• Linux的进程是抢占式
• 如果进程进入TASK_ RUNNING,内核检査它的动态优先级是否>当前正运行进程的优先级
• 是, current的执行被中断,并调用调度程序选择另一个进程运行(通常刚变为可运行的进程)。
• 进程在它的时间片到期时也可被抢占
• 此时,当前进程 thread info结构中的TIF_NEED_ RESCHED标志被设置,以便时钟中断处理程序终止时调度程序被调用

• 文本编辑程序和编译程序一一正在执行。
• 文本编辑程序是交互式程序,
  • 动态优先级高于编译程序。
• 编辑程序交替于用户暂停思考与数据输入之间,
  • 经常被挂起;
  • 两次击键之间的平均延迟较长。
  • 只要用户一按键,中断就发生,内核唤醒文本编辑进程。
  • 内核也确定编辑进程的动态优先级确实高于current的优先级(当前正运行的进程,编译进程),
  • 编辑进程的 TIE NEED RESCHIED标志被设,如此来强迫内核处理完中断时激活调度程序。
  • 调度程序选择编辑进程并进程切换;
  • 编辑进程很快恢复执行,并把用户键入的字符回显在屏幕上。
  • 处理完字符时,文本编辑进程自己挂起等待下一次击键,编译进程恢复执行

• 被抢占的进程并没被挂起,还处于TASK_ RUNNING
• 不过不再使用CPU。
• Linux2.6内核是抢占式的,
  • 进程无论是处于内核态还是用户态,
  • 都可能被抢占,
  • 第五章的“内核抢占”一节深入讨论过这个特征

调度算法

• 早期Linux
• 在每次进程切换时,内核扫描可运行进程的链表,
• 计算进程优先级,
• 选“最佳”进程来运行。
• 缺点是
  • 选择“最佳”进程所要消耗的时间与可运行的进程数量相关,
  • 运行数千个进程的高端系统中要消耗太多的时间

• 2.6调度算法复杂多。
• 该算法较好地解决了与可运行进程数量的比例关系,
• 它在固定的时间内(与可运行的进程数量无关)选中要运行的进程。
• 也很好地处理了与处理器数量的比例关系,
  • 因为每个CPU都拥有自己的可运行进程队列。
• 新算法较解决区分交互式进程和批处理进程。
• 在高负载系统中,
  • Linux2.6中交互应用的响应速度比早期的 Linux版本要快。

一个时间片必须持续多长?

• 长短对系统性能很关键
• 太短,由进程切换引起的系统额外开销就高。
  • 进程切换需要5ms
  • 时间片也设置为5ms,
  • 50%的时间花费在进程切换上(注2)。

• 太长,进程看起来就不是并发执行。
• 设为5s,每个可运行进程运行大约5s,但是暂停的时间更长(一般是5s乘以可运行进程的个数)。

• 长的时间片会降低交互式应用程序的响应时间,但这往往是错误
• 如前面“进程的抢占”描述,
• 交互式进程有较高的优先级,
• 不管时间片是多长,它们都会很快地抢占批处理进程。

• 一些情况下,太长的时间片会降低系统的响应能力。
• 两用户在各自的 shell提示符下并发输入两条命令,
• 一条启动一个CPU受限型的进程,
• 另条启动一个交互式应用。
• 两个 shell都创建一个新进程,并把用户命令的执行委托给新
  进程。
• 假定这样的新进程最初有相同的优先级( Linux预先并不知道执行进程是批处理的还是交互式的)。
• 如果调度程序选择CPU受限型的进程执行,则另个进程开始执行前就可能要等待一个时间片。因此,如果这样的时间片较长,那么看起
  来系统就可能对用户的请求反应迟钝。

• 对时间片大小的选择一种折衷。
• llinux采取单凭经验的方法,即选择尽可能长、同时能保持良好响应时间的一个时间片