Hardware • Definitions – Port: Point of connection – Bus: Interface • Daisy Chain (A=>B=>…=>X) • Shared Direct Device Access – Controller: Device Electronics – Registers: Device Storage for CPU to device communication – Handshakes: signals sent between devices and the CPU through shared memory or privileged I/O instructions • Issue (many devices & manufactures) • Solutions – Standard interfaces – Uniform drivers for device groups – Manufacturer provided drivers Device addresses for automatic probes CPU Device Control • Privileged I/O instructions control devices – Interface with device command-ready, busy, and error status registers • Direct memory I/O instructions – Ties devices to memory locations • Memory-mapped I/O – Reserved memory addresses control a device (E.g.: monitor display) • Simple Polling interface – Useful if device response is almost instantaneous (busy-wait) WHILE command-ready-register = device-not-ready THEN spin Issue send or receive command WHILE device is busy THEN spin (This is a busy wait loop) IF error and retry-count not expired THEN restart the command RETURN I/O complete Programmed IO • I/O raises the CPU Interrupt request line • At next instruction, the Interrupt occurs, and the CPU state saved • The Interrupt vector directs interrupts to the correct handler – Interrupt chaining ties multiple devices to a single vector entry – Some interrupts can be masked based on priority • Traps are software triggered interrupts Direct Memory Access (DMA) • • • • Used to avoid programmed I/O for large data transfers from fast devices Requires a DMA controller enabling devices to directly access memory CPU cycles are stolen for each memory reference The driver gives the DMA controller chains of addresses and lengths I/O Sub-system Purpose: Abstract, Encapsulate, and Layer Device-drivers: Encapsulate controller differences from kernel Device Categories I/O Subsystem Structure • Note: Some specialized devices have unique interfaces and drivers Device Categories by Speed Kernel Data Structures • Kernel maintains system-wide I/O components table • Kernel maintains free, used, “dirty” buffers in complex data structures • I/O Wait queues and cache buffering Device-status Table Application API • Block devices include disk drives – Commands include read, write, seek – Raw I/O or file-system access – Memory-mapped byte streams using virtual memory facilities • Character devices (keyboards, mice, serial ports) – Commands include get, put – Libraries layered on top allow line editing (backspace etc.) • Network devices – Incorporates protocol, flow control, and pipelining – Separates network protocol from network operation – Includes select functionality (socket port numbers) • Clocks and Timers for current time and elapsed time – Course grain regular interval interrupts – Programmable non-interruptible timers for fine grain resolution System Call to Perform I/O Categories of OS calls • Blocking - process suspended until I/O completed – Easy to use and understand – Insufficient for some needs • Non-blocking - I/O call returns as much as available – User interface, data copy (OS buffered I/O) – Implemented via multi-threading – Returns quickly with count of bytes read or written • Asynchronous - process runs while I/O executes – Difficult to use – I/O subsystem signals process when I/O completed • Direct Application control – ioctl (on UNIX) allows applications to directly control devices – Driver testing Additional OS I/O Subsystem Services • Caching - fast memory access to recently accessed data – Always just a copy – Significant performance impact • Spooling - hold output for a device – If device can serve only one request at a time – i.e., Printing • Exclusive device reservation • • • • – System calls for allocation and de-allocation – Deadlocks are possible Scheduling - Ordering the I/O requests in the per-device queue – Some OSs try fairness Buffering - store data in OS buffers during transfers – To cope with device speed or transfer size mismatches – To maintain “copy semantics”, and dirty buffers. Fault processing: Recovery through retry operations, error logs Miscellaneous: Pipes, FIFOs, packet handling, streams, queues, mailboxes Flow of an I/O Request • Consider request to read a file – What device? – Name translation – Copy between application and kernel buffer – Change process status to ready Streams • STREAM – flow from source to sink (process <--> device) – Full-duplex: flow in both directions – Stream head interfaces with the user process – Stream tail interfaces with the device – Stream wrappers enable data manipulation (filtering) at each level, which contain their own read/write queuing capabilities • Implementation – Message passing between adjacent queues – Multiple copies operations will increase overhead Performance • Potential bottlenecks: – CPU device processing – Context switches after processing interrupts – Copying between OS and user buffers – Routing network traffic • Performance improvements – Reduce context switches – Minimize data copying – Minimize interrupts and reduce latency by using large transfers, smart controllers, DMA – Balance CPU, memory, bus, and I/O contention for highest throughput I/O System flow illustrating bottlenecks Incorporate of new Devices Where should the device handling code go?