如我们已见到的, 忙等待强加了一个重负载给系统总体; 我们乐意找出一个更好的技术. 想到的第一个改变是明确地释放 CPU 当我们对其不感兴趣时. 这是通过调用调度函数而 实现地, 在 <linux/sched.h> 中声明:
while (time_before(jiffies, j1)) { schedule();
}
这个循环可以通过读取 /proc/jitsched 如同我们上面读 /proc/jitbusy 一样来测试. 但是, 还是不够优化. 当前进程除了释放 CPU 不作任何事情, 但是它保留在运行队列中. 如果它是唯一的可运行进程, 实际上它运行( 它调用调度器来选择同一个进程, 进程又调 用调度器, 这样下去). 换句话说, 机器的负载( 在运行的进程的平均数 ) 最少是 1, 并 且空闲任务 ( 进程号 0, 也称为对换进程, 由于历史原因) 从不运行. 尽管这个问题可 能看来无关, 在计算机是空闲时运行空闲任务减轻了处理器工作负载, 降低它的温度以及 提高它的生命期, 同时电池的使用时间如果这个计算机是你的膝上机. 更多的, 因为进程 实际上在延时中执行, 它所耗费的时间都可以统计.
/proc/jitsched 的行为实际上类似于运行 /proc/jitbusy 在一个抢占的内核下. 这是一 个例子运行, 在一个无负载的系统:
|
phon% dd |
bs=20 count=5 < /proc/jitsched |
|
1760205 |
1761207 |
|
1761209 |
1762211 |
|
1762212 |
1763212 |
|
1763213 |
1764213 |
|
1764214 |
1765217 |
有趣的是要注意每次 read 有时结束于等待比要求的多几个时钟嘀哒. 这个问题随着系统 变忙会变得越来越坏, 并且驱动可能结束于等待长于期望的时间. 一旦一个进程使用调度 来释放处理器, 无法保证进程将拿回处理器在任何时间之后. 因此, 以这种方式调用调度 器对于驱动的需求不是一个安全的解决方法, 另外对计算机系统整体是不好的. 如果你在 运行 load50 时测试 jitsched, 你可以见到关联到每一行的延时被扩充了几秒, 因为当 定时超时的时候其他进程在使用 CPU .