36.4 通过中断降低CPU开销

36.4 通过中断降低CPU开销

    多年前为了提升这种交互的性能，许多工程师发明了我们现在熟知的：中断。操作系统不是重复的轮询设备，而是发出一个命令，使请求设备的进程进入休眠状态，并且进行环境切换到另一任务。
当设备最终完成了操作，它将会发出一个硬件中断，在预定的中断服务程序中或者更简单的中断处理程序下使CPU跳进OS中。中断处理系统只是操作系统代码中的一部分，它将会完成请求（例如，通过读取数据和可能来自设备的错误代码）并且唤醒等待I/O的进程，这样进程就能如愿执行下去。
    因此，中断使得计算和I/O可以同时进行，这是提升利用率的关键。以下的时间线展示了这一点：
    在图中，进程1某段时间占用CPU（用CPU时间线上重复的1表示），然后它向硬盘发出一个I/O请求读取数据。在没有中断的情况下，系统简单的运行，反复的轮询设备状态直到I/O完成（图中用P表示）。硬盘响应了请求，最终进程1可以再一次在CPU中执行。
    如果我们利用中断，允许CPU和I/O并行，当等待硬盘操作时，操作系统干点别的事。
    在这个例子中，当硬盘为进程1提供服务时，操作系统可以将进程2调入CPU。当硬盘请求完成，发生中断，操作系统唤醒进程1然后再次执行它。因此，在图中重叠的时间段中，CPU和硬盘都得到了适当的使用。
    注意到，使用中断并不一直是最好的解决方案。例如，想象一个设备非常快地执行它的任务：在第一次轮询时间内任务通常都能完成。在这个系统中使用中断反而会减慢速度：切换到其他进程，处理中断然后切回被中断的进程，这一过程系统开销很大。因此，如果一个设备运行速度很快，那么最好的方式是采用轮询；如果它运行速度很慢，那么允许设备CPU并行的中断则是最好的方式。如果设备的速度是未知的，或者有些时候快，有些时候慢，那么最好的方式可能是混合的，即先轮询一小会，然后如果设备还不能响应，再使用中断。在上述情况下，这种两步的方法可能获得最好的效果。

TIP：中断并不一定一直优于PIO（Programming Input/Output Model，CPU控制I/O）。
尽管中断允许计算和I/O并发执行，但这只对低速设备有意义。另外，中断处理和环境切换的开销可能超过中断带来的好处。有这样的案例，大量的中断可能使得系统过载，并且导致活锁现象；在这样的例子中，轮询在调度中为操作系统提供更多的控制，因而又是有用的。
    另一个理由不去使用中断，出现在网络中。当巨量的即将到来的数据包每一个都产生一个中断的话，很可能使得操作系统活锁，即操作系统只顾着执行中断而不去执行用户进程也不响应请求。例如，想象一个web服务突然由于slashdot效应而受到大量访问。在这一案例中，最好是间或使用轮询来更好的控制系统，并且允许web服务在返回设备检查更多包裹到来之前，响应某些请求。

    另一种基于中断的优化方法是聚集。在这一方法中，当一个需要发出中断的设备向CPU递交中断之前，首先需要等待一小会。等待的过程中，其他的请求可能很快得到完成，然后多个中断可以聚集成一个中断递交给CPU,从而降低中断处理的开销。当然，等待太久，将会增加请求的延迟，这是系统中常见的权衡。见Ahmad et al.[A+11] ，有极好的总结。