Lowering CPU Overhead with Interrupts
In this lesson, we discuss how to reduce the overhead due to polling by using interrupts. We also discuss the limitations of this approach.
We'll cover the following
The invention that many engineers came upon years ago to improve this interaction between OS and a device, is something we’ve seen already: the interrupt. Instead of polling the device repeatedly, the OS can issue a request, put the calling process to sleep, and context switch to another task. When the device is finally finished with the operation, it will raise a hardware interrupt, causing the CPU to jump into the OS at a predetermined interrupt service routine (ISR) or more simply an interrupt handler. The handler is just a piece of operating system code that will finish the request (for example, by reading data and perhaps an error code from the device) and wake the process waiting for the I/O, which can then proceed as desired.
Improved utilization
Interrupts thus allow for overlap of computation and I/O, which is key for improved utilization. This timeline shows the problem:
In the diagram, Process 1 runs on the CPU for some time (indicated by a repeated 1 on the CPU line), and then issues an I/O request to the disk to read some data. Without interrupts, the system simply spins, polling the status of the device repeatedly until the I/O is complete (indicated by a p). The disk services the request and finally Process 1 can run again.
If instead we utilize interrupts and allow for overlap, the OS can do something else while waiting for the disk:
In this example, the OS runs Process 2 on the CPU while the disk services Process 1’s request. When the disk request is finished, an interrupt occurs, and the OS wakes up Process 1 and runs it again. Thus, both the CPU and the disk are properly utilized during the middle stretch of time.
Problem with interrupts
Note that using interrupts is not always the best solution. For example, imagine a device that performs its tasks very quickly: the first poll usually finds the device to be done with a task. Using an interrupt, in this case, will actually slow down the system because switching to another process, handling the interrupt, and switching back to the issuing process is expensive. Thus, if a device is fast, it may be best to poll. If it is slow, interrupts, which allow overlap, are best. If the speed of the device is not known, or sometimes fast and sometimes slow, it may be best to use a hybrid that polls for a little while and then, if the device is not yet finished, uses interrupts. This two-phased approach may achieve the best of both worlds.
TIP: INTERRUPTS NOT ALWAYS BETTER THAN PROGRAMMED I/O (PIO)
Although interrupts allow for overlap of computation and I/O, they only really make sense for slow devices. Otherwise, the cost of interrupt handling and context switching may outweigh the benefits interrupts provide. There are also cases where a flood of interrupts may overload a system and
; in such cases, polling provides more control to the OS in its scheduling and thus is again useful. lead it to livelock “Eliminating Receive Livelock in an Interrupt-driven Kernel” by Jeffrey Mogul, K. K. Ramakrishnan. USENIX ’96, San Diego, CA, January 1996. Mogul and colleagues did a great deal of pioneering work on web server network performance. This paper is but one example.
Another reason not to use interrupts
Coaslescing
Another interrupt-based optimization is coalescing. In such a setup, a device which needs to raise an interrupt first waits for a bit before delivering the interrupt to the CPU. While waiting, other requests may soon complete, and thus multiple interrupts can be coalesced into a single interrupt delivery, thus lowering the overhead of interrupt processing. Of course, waiting too long will increase the latency of a request, a common trade-off in systems. See
Get hands-on with 1400+ tech skills courses.