Chapter 13: I/O Systems

1. Chapter 13: I/O Systems • I/O Hardware • Application I/O Interface • Kernel I/O Subsystem • Transforming I/O Requests to Hardware Operations • Streams (skip 13.6) • Performance

2. Objectives • Explore the structure of an operating system’s I/O subsystem • Discuss the principles of I/O hardware and its complexity • Provide details of the performance aspects of I/O hardware and software

3. 13.1 Overview & 13.2 I/O Hardware • Incredible variety of I/O devices • Increasing standardization of software and hardware interfaces • Increasing broad variety of I/O devices • The device driversmodule present a uniform device-access interface to the I/O sub-system • Common concepts • Port – connection point of computer and a device • Bus (daisy chain or shared direct access) • Controller – a collection of electronics that can operate a port, a bus, or a device • SCSI bus controller (or host adapter) typically contains a processor, microcode, and some private memory

4. A Typical PC Bus Structure slow devices

5. 13.2 I/O Hardware • Question: How do the processor give commands and data to a controller to accomplish an I/O transfer? • Answer: The controller has one or more registers for data and control signals • Special I/O instructions control devices by specifying the transfer of a byte or a word into or out of a device register • The I/O instruction triggers bus lines to select the proper device and to move bits into or out of a device register • Alternatively,the controller can support Memory-mappedI/O • The device-control registers are mapped into the address space of the processor • Disadvantage: a memory-mapped device register is vulnerable to accidental modification. The risk could be reduced by protected memory

6. Device I/O Port Locations on PCs (partial)

7. 13.2 I/O Hardware • An I/O port typically consist of four registers • The data-in register: 1 to 4 bytes • The data-out register: 1 to 4 bytes • The status register • The control register • Possible state of device • command-ready • busy • error • Polling • Busy-waiting cycle: Reading the status register until the busy bit becomes clear (0)

8. Polling • Example: The host writes output through a port, coordinating with the controller by handshaking as follows: • The host repeatedly read the busy bit until the bit is cleared (0). • The host sets the write bit (1) in the command register and writes a byte into the data-out register • The host sets the command-ready bit. • When the controller notices 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, and clears the busy bit to indicate that it is finished

9. Interrupts • Polling becomes inefficient when it is attempted repeatedly yet rarely finds a device to be ready for service • Instead, use CPU Interrupt-request line triggered by I/O device • Interrupt-handlerroutine receives interrupts • Maskable to ignore or delay some interrupts • Interrupt vector to dispatch interrupt to correct handler • Based on priority • Some nonmaskable • Interrupt mechanism also used for exceptions

10. Interrupt-Driven I/O Cycle

11. Interrupts • In a modern OS, more sophisticated interrupt handling features are needed: • The ability to defer interrupt handling during critical processing • An efficient way to dispatch to the proper interrupt handler for a device without first polling all the devices to see which one raised the interrupt • Multi-level interrupts, so that the OS can distinguish between high- and low-priority interrupts and can respond with the appropriate degree of urgency • In modern computer hardware, these three features are provided by the CPU and by the interrupt-controller hardware skip p. 561 line 9 to end of 13.2.2 in p.563

12. 13.2.3 Direct Memory Access • Used to avoid burdening the main CPU with programmed I/O for large data movement • Requires DMA controller • Bypasses CPU to transfer data directly between I/O device and memory skip p. 564 最後一段

13. Six Step Process to Perform DMA Transfer cycle stealing

14. 13.3 Application I/O Interface • I/O system calls encapsulate device behaviors in generic classes – abstraction, encapsulation, software layering • Devices are abstracted to a few general kinds. Each general kind is accessed through a standardized set of functions -- an interface • Device-driver layer hides differences among I/O controllers from kernel

15. A Kernel I/O Structure

16. Characteristics of I/O Devices

17. Application I/O Interface • Devices vary in many dimensions • Character-stream or block • Sequential or random-access • Synchronous or asynchronous • Sharable or dedicated • Speed of operation • Read-write, read only, or write only • The major access conventions include • Block I/O • Character-stream I/O • Memory-mapped file access • Network sockets

18. 13.3.1 Block and Character Devices • Block devices include disk drives • Commands include read(), write(), seek() • Raw I/O or file-system access • Also for special applications such as DBMS • The special applications would provide their own locking and buffering. OS provides other services. – called direct I/O in UNIX. • Memory-mapped file access can be layered on top of block- device drivers • Provides access to the disk storage via an array of byes in main memory • Character-stream interface for character devices, such as keyboards, mice, serial ports • Commands include get(), put() • Libraries layered on top to offer line-at-a-time access

19. 13.3.2 Network Devices • Varying enough from block and character to have their own interface • Popular one is the socket interface • Unix and Windows NT/9x/2000 include socket interface • Separates network protocol from network operation • Includes the select() functionality • A call to select() returns information about which sockets have a packet waiting to be retrieved and which sockets have room to accept a packet to be sent • Approaches vary widely (pipes, FIFOs, streams, queues, mailboxes) skip 13.3.3

20. 13.3.4 Blocking and Nonblocking I/O • Blocking - process suspended until I/O completed • Easy to use and understand • Insufficient for some needs • Nonblocking - I/O call returns as early as available • For user interface (keyboard, mouse), video application (reading, decompressing, and displaying the output) • Implemented via multi-threading • Returns quickly with count of bytes read or written • Implemented via asynchronous system calls - I/O call returns immediately • Process continues without waiting while I/O executes • When I/O completed, I/O subsystem notifies process through setting of some variables, triggering a software interrupt, or call-back function • Difficult to use

21. Two I/O Methods Asynchronous Synchronous

22. 13.4 Kernel I/O Subsystem • I/O services provides by kernel • Scheduling, buffering, caching, spooling, device reservation, error handling, I/O protection • I/O Scheduling • Some I/O request ordering via per-device queue • Some OSs try fairness – no one application receives poor service • To support asynchronous I/O, it must keep track of many I/O requests at the same time • Use device-status table

23. Device-status Table

24. Kernel I/O Subsystem • Buffering - store data in memory while transferring between devices • To cope with device speed mismatch • Example: file received via modem for storage on the hard disk via double buffering (next slide shows the differences in device speeds) • To cope with device transfer size mismatch • Common in computer networking • To maintain “copy semantics” • The version of data written to disk is guaranteed to be the version on the time of the application system call, independent of any subsequent changes in the application’s buffer

25. Sun Enterprise 6000 Device-Transfer Rates

26. Kernel I/O Subsystem • Caching - fast memory holding copy of data • Always just a copy • Key to performance • Spooling – a buffer hat holds output for a device • If device can serve only one request at a time • Useful for printers and tape drives • Device reservation – coordination to provide exclusive access to a device • System calls for allocation and deallocation • Watch out for deadlock

27. Kernel I/O Subsystem • Error Handling • OS can recover from disk read, device unavailable, transient write failures • Most OS’s return an error number or code when I/O request fails • System error logs hold problem reports skip 13.4.5 第 2 段

28. Kernel I/O Subsystem • I/O Protection -- User process may accidentally or purposefully attempt to disrupt normal operation via illegal I/O instructions • All I/O instructions defined to be privileged • I/O must be performed via system calls • Memory-mapped and I/O port memory locations must be protected too

29. Use of a System Call to Perform I/O

30. 13.4.7 Kernel Data Structures • Kernel keeps state info for I/O components, including open file tables, network connections, character-device communications, etc. • Many, many complex data structures to track buffers, memory allocation, “dirty” blocks (see next slide) • Some use object-oriented methods • Windows NT uses a message passing mechanism to implement I/O

31. UNIX I/O Kernel Structure

32. 13.5 Transforming I/O Requests to Hardware Operations • Consider reading a file from disk for a process: • Determine device holding file • Translate name to device representation • Physically read data from disk into buffer • Make data available to requesting process • Return control to process skip 13.6

33. Life Cycle of An I/O Request

34. 13.7 Performance • I/O is a major factor in system performance. • It places heavy demands on the CPU to execute device-driver code and to schedule processes fairly and efficiently as they block and unblock • Interrupts handling is expensive -- context switches • Data copying between controllers and physical memory, and between kernel buffers and application data space • Network traffic can also cause a high context-switch rate • Consider a remote login (see next slide) • To eliminate the context switches involved in moving each character between daemons and the kernel, Solaris rei-mplemented the telnet daemon using in-kernel threads skip p.584 第 2 段

35. Intercomputer Communications

36. Improving I/O Performance • Principles • Reduce number of context switches • Reduce data copying • Reduce the frequency of interrupts by using large transfers, smart controllers, and polling • Increase concurrency by using DMA • Move processing primitives into hardware • Balance CPU, memory, bus, and I/O performance for highest throughput

37. Device-Functionality Progression