Chapter 13-2 IO Systems.ppt

13.* Silberschatz, Galvin and Gagne ?2005 Operating System Concepts Chapter 13-2: I/O Systems Chapter 13-2 I/O Hardware (continued) Application I/O Interface Chapter 13-3 Kernel I/O Subsystem Transforming I/O Requests to Hardware Operations Streams Performance Interrupts – How they Work CPU hardware simply has a wire (interrupt request line) it senses after executing every instruction. When the CPU detects signal on the line (set by the device controller), CPU performs a state save* and jumps to an interrupt handler routine in a fixed memory location down in the kernel I/O subsystem space. Please note: this save state does not necessarily mean context switching!! Current processing is suspended temporarily (can do context switching in general – but we will discuss this more ahead…) This interrupt handler determines the cause of the interrupt, performs the processing, restores the previous CPU state, and executes a return from the interrupt to return to the CPU to the execution state prior to the interrupt. Terminology: the device controller raises an interrupt; the CPU catches the interrupt, and dispatches it to the interrupt handler. The handler clears the interrupt after servicing the device See process on next slide. Interrupt-Driven I/O Cycle This graph is very high level…but: Saving state, etc. are part of this process but not shown in step 4 above… Restoring state and setting CPU back up to resume are implicit in steps 5 and 6. Interrupt Issues So, CPU is not polling and potentially wasting time. CPU thus responds to an asynchronous event. Unfortunately, interrupt handling causes many additional problems and issues that need to be resolved. We will consider many of these… Here’s one issue: Without actual polling, how is it determined what is the appropriate interrupt handler to branch to without knowing the device (who raised the interrupt?) caused the interrupt? Too: all interrupts are not created equal! Some must be serviced immediately