如我们已见到的, 忙等待强加了一个重负载给系统总体; 我们乐意找出一个更好的技术. 想到的第一个改变是明确地释放 CPU 当我们对其不感兴趣时. 这是通过调用调度函数而 实现地, 在 中声明:

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 .