CS 346 Chapter 12 IO systems Hardware components

CS 346 – Chapter 12 • I/O systems – – Hardware components Polling & interrupts DMA: direct memory access I/O & the kernel

I/O • Challenge: so many different I/O devices • Try to put a lid on complexity – Classify I/O by how they behave – All devices should have a common set of essential features • Each device has a controller (hardware / circuitry) that is compatible to the host machine. – Process running on CPU needs to read/write values in registers belonging to an I/O controller • Corresponding device driver installed as part of the OS – Communicates with controller – I/O instructions ultimately “control” the devices • Devices can have memory addresses allocated to them

Concepts • Port – physical connection point between device and computer • Bus – set of wires connecting 1+ devices – The bus itself is connected to the port, and devices are connected to the bus – Figure 12. 1: Notice controllers connected to bus – System enforces some protocol for communication among the devices along this bus • Daisy chain – another way to group devices – One device is connected directly to the computer – Each other device is connected to another device along the chain. Think of it as a linked list of devices, with the first device directly connected.

Memory mapped I/O • Some of RAM is reserved to allow processes to communicate with I/O controllers • We read/write data to specific address – This address is assigned to a specific port identify device – Each device is given a specific range of addresses: Fig. 12. 2 – Address also signifies meaning of the value. E. g. Status of I/O request, command to issue to controller, data in, data out • An I/O instruction can immediately get/set a value in controller’s register

Polling & interrupts • When working with an I/O device, we need to determine its state: is it ready/busy, did it encounter an error or complete successfully? • Polling = busy-wait cycle to wait for answer from device. Periodically check status of operation • Interrupt – let the I/O device inform me – Device sends signal along an interrupt-request line – CPU detects signal and jumps to predefined interrupt handling routine. (Need to save state while away) Figure 12. 3 – Nature of signal allows us to choose appropriate handler – Some interrupts maskable: can ignore – What I/O interrupts do we encounter?

Direct memory access • Used to large transfer of data – E. g. reading contents of a file into memory • DMA controller does I/O between device and memory independent of and parallel with CPU execution • Figure 12. 5 example – Process in CPU sends command to DMA controller identifying source and destination locations. – CPU goes about its business. DMA controller & device driver do the rest, communicating with the disk controller. – DMA tells disk to transfer a chunk of data to memory location X. – Disk controller sends individual bytes to DMA controller – DMA controller keeps track of progress. When done, interrupt CPU to announce completion.

Application I/O interface • In order to help the OS define appropriate system calls, we need to know what devices can do for us • Classify device personality. Such as: – Character-stream or block? – Sequential or random access desired? – Synchronous or asynchronous, i. e. predictable or unpredictable response times? • Example devices (Figure 12. 7) – – Terminal is character-stream oriented Disk is block oriented, and can both read & write data Keyboard is asynchronous Graphics card is write-only • Question: what use can we make of clock?

• I/O systems, continued – – …Features of I/O system calls Kernel responsibilities Buffer, cache, spool Performance issues

System call behavior • Clocks – Some I/O requests may be periodic, or set to occur at a specific time – Fine grain (cycle): look up the time – Coarse grain: HW clock generates timer interrupts approx. every 1/60 of a second. Why so seldom? • Blocking vs. nonblocking I/O – Blocking: put yourself to sleep while waiting for completion. More straightforward to code – Nonblocking: you want to keep going while waiting. Response time is important. Example? • If it’s short and quick: have another thread get the data • Usually: use asynchronous system call, and wait for I/O interrupt or “event” to take place

Kernel’s job • I/O scheduling – – Critical task since inherently slow 2 goals: minimize average response time; fairness Rearrange order of I/O requests as they enter “queue” Ex. Using the elevator algorithm for disk access • Error handling – Transient failures occur: prepare to retry I/O calls – I/O system calls can return an errno • Protection – We don’t want users to directly access I/O instructions. – All I/O requests need to be checked by kernel – Memory-mapped memory areas should be off limits to direct user intervention. (unnecessary and invites bugs)

Buffers • Memory area between device and application temporarily holding data. Motivation… • Different speeds of producer & consumer (Fig. 12. 10) – Would be nice to do one disk operation; wait until a whole disk block can be written to, not just 1 line of text. – Why do we use “double buffering”? • Different size units – Not everything is the same size as a disk block, page frame, TCP packet, etc. • Spool = buffer where output cannot be interleaved from different sources: printing – Create temporary “file” for each print job print queue – Managed by dedicated daemon process

Preparing HW ops • Many steps, common example is reading file from disk • Before we can communicate with disk controller, need to locate file – File system identifies the device containing the file (how? ) – Determine which disk blocks comprise the file (how? ) • Life cycle of I/O request begins! – – – Note that: A device has a wait queue (why? ) Use DMA if the amount of data is large Small data can be kept in a buffer Lots of signalling/interrupts going on End result: I/O system call returns some value to user process. Let’s go through the steps

Performance issues • I/O incurs many interrupts • Each interrupt causes a context switch – we’d like to minimize these • Ex. When logging in to a remote machine, don’t create a network message for every keyboard interrupt • Don’t copy data too many times unnecessarily • Where to implement I/O: various levels: – User space, kernel space, device driver – Microcode on device controller or in the makeup of device • Trends to observe among the levels (Fig. 12. 16) – Cost of mistake; efficiency; development cost; flexibility