1 / 39

CHAPTER 13: I/O SYSTEMS

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

Thomas
Download Presentation

CHAPTER 13: I/O SYSTEMS

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 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,

  3. I/O HARDWARE • Introduction • Polling • Interrupts • DMA

  4. I/O Hardware A typical PC bus structure

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

  6. I/O Hardware Some typical ports on PCs

  7. I/O Hardware • Three interaction models between I/O controllers and CPUs • Polling • Interrupt • DMA

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

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

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

  11. I/O Hardware: Interrupts

  12. I/O Hardware: Interrupts

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

  14. I/O Hardware: DMA

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

  16. I/O API

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

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

  19. I/O API: Network Device Interfaces • Varying enough from block and character to have own 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)

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

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

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

  23. 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” (kernel memory space v.s. user memory space)

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

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

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

  27. I/O Kernel Subsystem

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

  29. 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 <major,minor> • To read the inode • To get the location of data blocks

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

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

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

  33. STREAMS

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

  35. Performance: Network traffic

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

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

  38. Lab • System programming • System calls • strace

More Related