Chap 1: Introduction - Zhejiang University

Download Report

Transcript Chap 1: Introduction - Zhejiang University

CHAPTER 13: I/O SYSTEMS

 Overview  I/O Hardware  I/O API  I/O Subsystem  Transforming I/O Requests to Hardware Operations  Streams  Performance

OVERVIEW

 Incredible variety of I/O devices  Increasing standardization of I/O hardware and software interface  Increasingly broad variety of I/O devices  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  Polling  Interrupts  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  Direct I/O instructions  Memory-mapped I/O  Direct I/O + memory mapped I/O  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  Polling  Interrupt  DMA

I/O Hardware: Polling

 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  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  Interrupt handler receives interrupts  Maskable to ignore or delay some interrupts  Interrupt vector to dispatch interrupt to correct handler  Based on priority  Some unmaskable, some maskable  Interrupt mechanism also used for  exceptions and  system calls  Interrupt handlers can be divided into two  Top half  Bottom half

I/O Hardware: Interrupts

I/O Hardware: Interrupts

I/O Hardware: DMA

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

I/O Hardware: DMA

I/O API

  I/O system calls encapsulate device behaviors in generic classes.

Device-driver layer hides differences among I/O controllers from kernel.

I/O API

I/O API

 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.

 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:  Commands include read, write, seek  Raw I/O or file-system access  Memory-mapped file access possible  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  Unix and Windows NT/9

i

/2000 include socket interface  Separates network protocol from network operation  Includes select functionality  Man other approaches (pipes, FIFOs, streams, queues, mailboxes)

I/O API: Clocks and Timers

 Provide current time, elapsed time, timer  If programmable interval time used for timings, periodic interrupts  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  Easy to use and understand  Insufficient for some needs  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  Difficult to use  I/O subsystem signals process when I/O completed

I/O KERNEL SUBSYSTEM

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

I/O Kernel Subsystem

 Scheduling  I/O request queue for a device  Some OSs try fairness (disk I/O)  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 ” space v.s. user memory space) (kernel memory

I/O Kernel Subsystem

 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  If a device can serve only one request at a time  i.e., Printing  Device reservation - provides exclusive access to a device  System calls for allocation and deallocation  Watch out for deadlock

I/O Kernel Subsystem

 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  Many, many complex data structures to track buffers, memory allocation, “ dirty ” blocks  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:  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?

 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 read the inode  To get the location of data blocks

I/O Requests to Hardware Operations : Life Cycle of An I/O Request  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 itself • The device driver allocates the buffer to receive the data, and performs the data transfer • The driver gets the data and interrupts the OS • 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  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.

 Message passing is used to communicate between queues.

 Flow control is used to regulate the flow.

STREAMS

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 data copying  Reduce interrupts by using large transfers, smart controllers, polling  Use DMA  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,  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)  Debugging is difficult, but fast.  To reimplement the code at the controller or device (hardware)  Fastest, Less flexible.

Lab  System programming  System calls  strace