Notes on the Use of Interrupts and DMA by N.

Guydosh 2/9/2002 The interrupt mechanism is built into the instruction processing cycle of the CPU hardware as can be seen from fig. 1 below (based on Operating systems, 4th ed. by Stallings, prentice Hall publ., p. 20, henceforth referred to as Stallings):

fig. 1 The granularity of an interrupt is a single machine instruction. The check for pending interrupts and processing of interrupts is done between instructions being executed, ie., the current instruction is completed before a pending interrupt is processed. The simplest scheme is to only process one interrupt at time, so that if an interrupt occurred during the servicing of a prior interrupt, the new interrupt would be queued, allowing the current interrupt processing to be completed. A more sophisticated scheme would allow nested interrupts. In this case, a priority scheme would be followed, and if a new interrupt occurred during the processing of some other interrupt, the new interrupt would preempt the processing of the first interrupt if it had a higher priority, allowing the new interrupt to get processed. On completion of the new preempting interrupt, the old interrupt would then continue its processing, or some other queued up pending interrupt having higher priority would get processed. See Figure 2 for an example taken from Stallings.

Fig. 2 The scenario below demonstrates the use of interrupts in performing an I/O operation. Assume a series of I/O requests occurs in a stream of instructions for a user process as shown below. Assume that the I/O request is for data transfer, meaning that it could be either a read or write operation. If the operation is a write, the CPU writes data from main memory to the I/O controller buffer, and then the controller writes from the buffer to the device. If the operation is a read, the controller puts input data from the device into the controller buffer and then the CPU reads the data from the buffer to main memory. Figure 3 (Stallings, p. 18) below illustrates this operation for three cases. In each case, the diagram represents an instruction stream in which two or more I/O requests are embedded. The main line program is labeled 1, 2, and 3. In each case the I/O request jumps to an I/O program which breaks into the mainline program. The I/O program has three parts labeled: 4, I/O cmd and 5. Part 4 is where he CPU sets up and moves the data from memory to the controller buffer for a write operation. The I/O command (cmd) is where the I/O controller does the actual I/O (moving data between the buffer and the device). This command is generally significantly slower than any CPU processing associated with the operation and will be a major performance bottle-neck if done serially with CPU processing. Part 5 is post processing of the I/O operation which includes moving the data from the controller buffer to main memory in the case of a read operation.

Fig. 3

Case (a): No interrupts: The path of execution is: 1, 4, I/O cmd, 5, 2, . The I/O cmd delay is in the critical path of CPU execution. During this time, the CPU must poll controller registers in a tight loop to determine when the operation completes. This is a waste of CPU cycles. Case (b): Interrupts with short I/O wait: The delay associated with the I/O operation is relatively short compared to the interval between I/O requests, that is, interrupts from a given I/O request will occur before the next request. The CPU still does part 4 of the I/O program serially with code in part 1 or 2. But when the I/O command is encountered, control is immediately returned to the user program, and the I/O controller overlaps the I/O operation with CPU processing. The CPU will continue with part 2 (or part 3 for the second request) of the code during this time. When the I/O operation is completed, the controller issues an interrupt to the CPU during part 2 of the code in this case (or part 3 for the second request). This is shown by the * symbols in the diagram. When the interrupt occurs, the CPU will automatically jump to the interrupt handling routing which would transfer data from the controller buffer to main memory (in the case of a read) along with any post I/O processing. After the interrupt handler is finished, execution of code in parts 2 or 3 is resumed. This scheme has significantly improved performance over case (a), because the CPU delay for the I/O operation has been eliminated. Case (c): Interrupts with long I/O wait: This case is similar to (b), with the exception that the I/O operation is longer than the intervening processing time between I/O requests. In fig. 3, the first I/O request is shown as running into the next consecutive I/O request. This case with result in partial overlap of the I/O operations because request 2 cannot be started (must be delayed) until the interrupt from request 1 is received. The CPU will thus wait for the first request to complete before starting the second request. In figure 3(c) The second I/O request path A5B which is the interrupt handling code for the first request, must be completed before the preparation code (C4D) is done for the second request. The CPU will wait for this to complete. But even in this case interrupts are superior to polling, because the entire processing in code part 2 is overlapped with the I/O CMD delay. The program timing for these cases are illustrated in figures 4 and 5 below (annotated from Stallings).

Fig. 4

Fig. 5

DMA Notes The use of DMA eliminates either I/O processing part 4 (for output), or I/O processing part 5 (for input) by having the DMA controller take over the job of moving data between the I/O controller buffer and main memory. During this time the CPU can move on and continue processing while data is being transferred between memory and the controller buffer. Interrupts are still used to inform the CPU that the DMA operation is complete. Figure 6 (Stallings, p. 36) compares the cases of polling, a pure interrupt scheme (as in fig 3. b and c), and DMA. A read operation is considered in each case:

Fig. 6 DMA is used in moving large blocks of data at high speeds in a single I/O request rather than a word or byte for each request because the overhead associated with moving words/bytes with a pure interrupt scheme would be intolerable for high speed I/O operations. The pure interrupt approach on word/byte basis is acceptable for situation in which the interval between words/bytes is relatively long compared to the overhead in processing the request.