CHAPTER 13: I/O SYSTEMS Overview Overview I/O Hardware I/O Hardware I/O API I/O API I/O Subsystem I/O Subsystem Transforming I/O Requests to Hardware Operations Transforming I/O Requests to Hardware Operations Streams Streams Performance Performance

OVERVIEW Incredible variety of I/O devices Incredible variety of I/O devices  Increasing standardization of I/O hardware and software interface  Increasingly broad variety of I/O devices Common concepts Common concepts  Port  Bus (daisy chain or shared direct access)  PCI, ISA, SCSI  Controller (host adapter)  Serial port controller, SCSI controller, IDE controller,

I/O HARDWARE Introduction Introduction Polling Polling Interrupts Interrupts DMA DMA

I/O Hardware A typical PC bus structure

I/O Hardware How can the processor give commands and data to a controller to accomplish an I/O transfer How can the processor give commands and data to a controller to accomplish an I/O transfer  Direct I/O instructions  Memory-mapped I/O  Direct I/O + memory mapped I/O I/O controller has 4 types of registers I/O controller has 4 types of registers  Status registers  Control registers  Data-in registers  Data-out registers

I/O Hardware Some typical ports on PCs

I/O Hardware Three interaction models between I/O controllers and CPUs Three interaction models between I/O controllers and CPUs  Polling  Interrupt  DMA

I/O Hardware: Polling Two bits Two bits  The busy bit indicates if the controller is busy or not working.  The command-ready bit indicates if the a command is available or not for the controller to execute. An example An example  The host repeatedly reads the busy bit until that it becomes clear (busy waiting or polling)  The host sets the write bit in the command register and writes a byte into the data-out register

I/O Hardware: Polling  The host sets the command-ready bit  When the controller notices that the command- ready bit is set, it sets the busy bit  The controller reads the command register and sees the write command. It reads the data-out register to get the byte, and does the I/O to the device.  The controller clears the command-ready bit, clears the error bit in the status register to indicate that the device I/O succeeded, and clears the busy bit to indicate that it is finished.

I/O Hardware: Interrupts CPU Interrupt request line triggered by I/O device CPU Interrupt request line triggered by I/O device Interrupt handler receives interrupts Interrupt handler receives interrupts Maskable to ignore or delay some interrupts Maskable to ignore or delay some interrupts Interrupt vector to dispatch interrupt to correct handler Interrupt vector to dispatch interrupt to correct handler  Based on priority  Some unmaskable, some maskable Interrupt mechanism also used for Interrupt mechanism also used for  exceptions and  system calls Interrupt handlers can be divided into two Interrupt handlers can be divided into two  Top half  Bottom half

I/O Hardware: Interrupts

I/O Hardware: DMA Used to avoid programmed I/O for large data movement Used to avoid programmed I/O for large data movement Requires DMA controller Requires DMA controller Bypasses CPU to transfer data directly between I/O device and memory Bypasses CPU to transfer data directly between I/O device and memory Cycle stealing Cycle stealing

I/O Hardware: DMA

I/O API I/O system calls encapsulate device behaviors in generic classes. I/O system calls encapsulate device behaviors in generic classes. Device-driver layer hides differences among I/O controllers from kernel. Device-driver layer hides differences among I/O controllers from kernel.

I/O API

On one hand, there are so many different I/O devices. On one hand, there are so many different I/O devices. On the other hand, the OS should provide a simple, uniform I/O API. On the other hand, the OS should provide a simple, uniform I/O API. The solution is the OS should hide (encapsulate) these differences and provide just a few types of device access. The solution is the OS should hide (encapsulate) these differences and provide just a few types of device access.  Block and character devices  Network Devices  Clocks and Timers

I/O API: Block and Character Device Interfaces Block devices include disk drives and other block- oriented devices: Block devices include disk drives and other block- oriented devices:  Commands include read, write, seek  Raw I/O or file-system access  Memory-mapped file access possible Character devices include keyboards, mice, serial ports Character devices include keyboards, mice, serial ports  Commands include get, put  Libraries layered on top allow line editing

I/O API: Network Device Interfaces Varying enough from block and character to have own interface Varying enough from block and character to have own interface Unix and Windows NT/9i/2000 include socket interface Unix and Windows NT/9i/2000 include socket interface  Separates network protocol from network operation  Includes select functionality Man other approaches (pipes, FIFOs, streams, queues, mailboxes) Man other approaches (pipes, FIFOs, streams, queues, mailboxes)

I/O API: Clocks and Timers Provide current time, elapsed time, timer Provide current time, elapsed time, timer If programmable interval time used for timings, periodic interrupts If programmable interval time used for timings, periodic interrupts ioctl (on UNIX) covers odd aspects of I/O such as clocks and timers ioctl (on UNIX) covers odd aspects of I/O such as clocks and timers

I/O API: Blocking and non-blocking I/O Blocking - process suspended until I/O completed Blocking - process suspended until I/O completed  Easy to use and understand  Insufficient for some needs Nonblocking - I/O call returns as much as available Nonblocking - I/O call returns as much as available  User interface, data copy (buffered I/O)  Implemented via multi-threading  Returns quickly with count of bytes read or written Asynchronous - process runs while I/O executes Asynchronous - process runs while I/O executes  Difficult to use  I/O subsystem signals process when I/O completed

I/O KERNEL SUBSYSTEM I/O scheduling I/O scheduling Buffering Buffering Caching Caching Spooling and device reservation Spooling and device reservation Error handling Error handling Kernel data structures Kernel data structures

I/O Kernel Subsystem Scheduling Scheduling  I/O request queue for a device  Some OSs try fairness (disk I/O) Buffering - store data in memory while transferring between devices Buffering - store data in memory while transferring between devices  To cope with device speed mismatch (modem vs disk)  To cope with device transfer size mismatch (packet vs frames)  To maintain “ copy semantics ” (kernel memory space v.s. user memory space)

I/O Kernel Subsystem Caching - fast memory holding copy of data Caching - fast memory holding copy of data  Always just a copy  Key to performance  Note: A buffer may hold the only existing copy of a data item, whereas a cache just holds a copy on a faster storage of an item that that resides elsewhere. Spooling - hold output for a device Spooling - hold output for a device  If a device can serve only one request at a time  i.e., Printing Device reservation - provides exclusive access to a device Device reservation - provides exclusive access to a device  System calls for allocation and deallocation  Watch out for deadlock

I/O Kernel Subsystem Error handling Error handling  OS can recover from disk read, device unavailable, transient write failures  Most return an error number or code when I/O request fails  System error logs hold problem reports

I/O Kernel Subsystem Kernel keeps state info for I/O components, including open file tables, network connections, character device state Kernel keeps state info for I/O components, including open file tables, network connections, character device state Many, many complex data structures to track buffers, memory allocation, “ dirty ” blocks Many, many complex data structures to track buffers, memory allocation, “ dirty ” blocks Some use object-oriented methods and message passing to implement I/O Some use object-oriented methods and message passing to implement I/O

I/O Kernel Subsystem

TRANSFORMING I/O TO HARDWARE OPERATIONS Consider reading a file from disk for a process: Consider reading a file from disk for a process:  Determine the device holding a file  Translate the name to the device representation  Physically read data from disk into buffer  Make data available to the requesting process  Return control to the process

I/O Requests to Hardware Operations : The connection between a filename and its disk controller How to map a filename to its disk controller? How to map a filename to its disk controller?  For DOS, C:\junk.txt  To find the partition  To read the starting entry from FAT  For Unix, /zapp/root/  To find the longest match from the mount table  To get  To get  To read the inode  To get the location of data blocks

I/O Requests to Hardware Operations : Life Cycle of An I/O Request Read Read  Sys_read  If in the cache, read from the cache  Otherwise, read from the hard disk Issue a read request and add itself to the queue and block itselfIssue a read request and add itself to the queue and block itself The device driver allocates the buffer to receive the data, and performs the data transferThe device driver allocates the buffer to receive the data, and performs the data transfer The driver gets the data and interrupts the OSThe driver gets the data and interrupts the OS The process will be unblocked.The process will be unblocked.

I/O Requests to Hardware Operations : Life Cycle of An I/O Request

STREAMS STREAM – a full-duplex communication channel between a user-level process and a device STREAM – a full-duplex communication channel between a user-level process and a device A STREAM consists of: A STREAM consists of: - STREAM head interfaces with the user process - driver end interfaces with the device - zero or more STREAM modules between them. Each module contains a read queue and a write queue. Each module contains a read queue and a write queue. Message passing is used to communicate between queues. Message passing is used to communicate between queues. Flow control is used to regulate the flow. Flow control is used to regulate the flow.

STREAMS

PERFORMANCE I/O is a major factor in system performance: I/O is a major factor in system performance:  Demands CPU to execute device driver, kernel I/O code  Context switches due to interrupts  Data copying  Between controllers and kernel  Between kernel space and user space  Network traffic especially stressful  See the next slide

Performance: Network traffic

Performance: How to improve Reduce number of context switches Reduce number of context switches Reduce data copying Reduce data copying Reduce interrupts by using large transfers, smart controllers, polling Reduce interrupts by using large transfers, smart controllers, polling Use DMA Use DMA Balance CPU, memory, bus, and I/O performance for highest throughput Balance CPU, memory, bus, and I/O performance for highest throughput

Performance: Where to implement To implement experimental I/O algorithms at the application level, To implement experimental I/O algorithms at the application level,  because application code is flexible, and application bugs are unlikely to cause system crashes.  Avoiding rebooting or reloading device driver To reimplement the code at the kernel (driver) To reimplement the code at the kernel (driver)  Debugging is difficult, but fast. To reimplement the code at the controller or device (hardware) To reimplement the code at the controller or device (hardware)  Fastest, Less flexible.

Lab System programming System programming  System calls  strace