Chapter 5: Device Management

1. Chapter 5: Device Management Prof. Steven A. Demurjian, Sr. † Computer Science & Engineering Department The University of Connecticut 191 Auditorium Road, Box U-155 Storrs, CT 06269-3155 steve@engr.uconn.edu http://www.engr.uconn.edu/~steve (860) 486 - 4818 † These slides have been modified from a set of originals by Dr. Gary Nutt.

2. Purpose of this Chapter • Device Drivers and Interrupt Handlers • Four Pronged Approach • Device Management Approaches • Direct I/O w/Polling & Interrupt Driven I/O • Memory Mapped I/O & Direct Memory Access • Impact of Buffering on I/O Performance • Device Reads in Anticipation of Request • Stage Data for Writing During Idle Periods • Generic Details of Device Driver Organization • Device Specific Considerations that Impact Management of Devices in an OS • Impact of Performance - Optimization for Disks

3. Device Management Approaches • What are Key Issues and Concerns? • How is I/O Handled by Drivers and CPU? • What is the CPU Involvement? • What is Overall Impact on OS Performance? • What Strategies Can Compartmentalize Device Driver Structure and What is Benefit? • Four Approaches • Direct I/O w/Polling to Detect I/O Completion • Interrupt Driven I/O - Software Controlled • Memory Mapped I/O • Direct Memory Access to Limit CPU Usage • We’ll Review and See Examples of Each

4. Device Management Organization Application Process API File Manager Device Driver Hardware Interface Command Status Data Device Controller • DD API Same Across All Similar Devices • Files Stored on Disks, Tapes, DVDs, etc. • DD Contains Device Specific Implementation • Code of APIs is Char. vs. Block Oriented

5. Direct I/O with Polling • CPU Responsible for Transferring Data • Primary Memory To/From Device Controller Data Registers • Remember, Controller is Hardware! • Multi-Step Read Process • Application Requests Read • Driver Queries Status Register for StateIf Busy - Wait • Driver Stores Input Request in Controller’s Command Register - Starts the Device (HW) • Driver Checks Status Register - Done Yet? • Driver Copies Controller’s Data Registers into Applications’s Process Space

6. Direct I/O with Polling (Read) read(device, …); Data 1 System Interface read function 5 write function 2 3 4 Hardware Interface Command Status Data Device Controller • How Does the Process work for Write Requests? • What is Key Problem? • Is CPU Too Involved? • Where are Excess CPU Cycles Used? • Why does OS Care about Excess CPU Cycles?

7. Interrupt Driven I/O • Motivation: Remove Need for Driver (Hence CPU) to Constantly Poll Controller Status Register (CSR) • Redesign/Partition Device Management as • Top-Half Driver: Initiates I/O, Saves Status, and Terminates • Device Status Table: Shared Data Structure by All Devices for Currently Executing I/Os • Interrupt Handler: Shared by All Devices • Notified by Controller (HW) of Completion • Determines Device that Finished • Branches to Device Handler • Device Handler: Bottom Half • Copies Controller’s Data Registers into User Space • Returns Control to Application Process

8. Interrupt Driven I/O (Read) 9 8b 1 7 4 2 6 8a 3 5 read(device, …); Data System Interface Device Status Table Device Handler read driver write driver Interrupt Handler Hardware Interface Command Status Data Device Controller

9. Observations • Viewpoint from Application Program • Procedure Call to “Read” • In Polling, Read Waits in Driver • In Interrupt, Read Waits in Application • What’s are Potential Benefits? • Reduction of Program Execution Time • Elimination of CPU Cycles Due to Polling • Balanced Against Extra Overhead for DST/IH • Regardless of Approach … • Guarantee of Serial Execution Semantics • SWE/Application “Sees” Serialized Execution • Possibility of Interrupt Driven Approach by SWE in Their Own Applications to Control Actions

10. Overlapping CPU Execution with I/O Data on device Variable x Register CPU Device dev_I Memory • Read Must Wait for Completion • Else, y=f(x)Could Use Old Value of x in Call . . . startRead(dev_I, “%d”, x); . . . while(stillReading()) ; y = f(x) . . . . . . read(dev_I,“%d”,x); y = f(x) . . . Logically Equivalent

11. Memory Mapped I/O • Devices Must have Memory via Which Information/Status Can be Exchanged for I/Os • Traditional Approach Employs Dedicated Memory for Device Addresses • Addressing/Access More Complex • Requires Dedicated Instruction Set • copy_in R3, 0x012, 4 • Modern Approach Utilizes Dedicated Portion of Primary Memory • Addressing/Access Simplified • Exploits Existing Instruction Set • store R3, 0xFFFF0124 • Memory Mapped I/O Reduces Instruction Set

12. Separate Device Addrs. Memory Mapped I/O Addressing Devices Primary Memory Primary Memory Memory Addresses Memory Addresses Device 0 Device 0 Device 1 Device 1 Device Addresses Device n-1 Device n-1

13. Direct Memory Access (DMA) Primary Memory Device • Device Controller Writes/Reads Directly to Primary Memory Independent of CPU • Saves CPU Cycles by Simplifying Process • What Possible Problem is Introduced? BUS CONTENTION OF DEVICES AND CPU CPU BUS

14. Direct Memory AccessTraditional I/O vs. DMA Primary Memory CPU Controller Device • What’s Advantage of DMA? • Can DMA Work with Polling? • Can DMA Work with Interrupt I/O? • What is Impact of DMA by Different Devices? • Drives • Network Card • Display • Other? Primary Memory CPU Controller Device

15. I/O - CPU Overlap Appl 1 Appl 2 I/O Ctlr Appl I/O Ctlr t1 t2 t3 t4 Overlapping Appl 1’s I/O with Appl 2 t1 t2 t3 t4 t5 t6 t7 t8 t9 Overlapping Appl CPU with its own I/O

16. Buffering • Input Buffering: • Input Device Reads into Primary Memory Before Request from Process • Can “Guess” what is Needed Next? • Based on Locality of Access • Output Buffering: • Save Info in Memory and Writing to Device While Process Continues Execution (DMA) • How Does Buffering Enhance Performance? • I/O Bound Computations (DB Access) • CPU Bound Computations (Prime Numbers) • How is Buffering Handled for Character Devices? Block-Oriented Devices? Tradeoffs?

17. Hardware Buffering of Modem Character Device Process Process Process Controller Controller Controller Data A B A B Device Device Device Process reads bi Controller reads bi+1 Process reads bi-1 Controller reads bi Unbuffered • Device (HW) Buffers Next Character to Controller (HW) as Process Reads Prior Character • Overlap of Read with CPU Execution

18. Double Buffering in the Driver • Technique to Exploit Hardware and Software • Driver/Controller • One Buffer Level • As Described • Device Driver • Another Buffer Level • Oscillation • Process Always has Two Characters Waiting • In Controller • In Driver Process A B Driver Controller A B Hardware Device

19. Double Buffering in the Driver Process Process A B A B Driver Controller Controller A B A B Hardware Device Device

20. A Ring Buffer • What are Potential Circular Buffering Problems? • Producer Passes Consumer - Overwriting • Consumer Passes Producer - Reads Stale Data • I/O Bound - Never Empty Buffers • CPU Bound - Always Full Buffers To data consumer Buffer i Buffer j From Data Producer

21. Program Phases: Compute vs. I/O Bound • Over Time, Program Exhibits Both I/O Bound and Compute-Bound Behavior • Remember, Buffering at Varied Levels • Keyboard and Modem • Network and Disks Compute-bound Time I/O-bound

22. Device DriversOrganization and Approach • Recall Device Manger Contains Device Driver to Process I/O Calls by Applications • What are Software Design and Engineering Goals for Constructing Device Manager? • API Implements I/O Functions of DeviceAPI Compliant with Other “Similar” Devices • Kernel Interface: Realize Coordination Among Processes, Drivers, Handlers, and Controller • Optimize for Performance • Key Issue: Provide Resource Abstractions While Achieving Above Goals

23. Application Programming Interface • Functions Available to Application Programs • Abstract All Devices to a Few, Well-Defined Interfaces • Make Interfaces As Similar As Possible • Differentiate Between “Classes” of Devices • Block-Oriented vs. Character-Oriented • Sequential vs. Random/Direct Access • Examples of Each? • Device Driver Implements Functions (One Entry Point Per API Function) • Is it Possible to Write a Device Driver API to Read/Write Entire Objects? What About Object Serialization in JAVA?

24. Sample APIBSD UNIX Driver • In Unix, ioctl Passes Driver Specific Information to Driver • Differentiation Between Block and Character I/O Processing as Part of Uniform API open Prepare dev for operation close No longer using the device ioctl Character dev specific info read Character dev input op write Character dev output op strategy Block dev input/output ops select Character dev check for data stop Discontinue a stream output op

25. The Driver-Kernel Interface • Driver Separate from User Process - Part of OS Since Executes Supervisor-Level Instructions • Drivers Separate From Rest of Kernel • Kernel Makes Calls on Specific Functions, Drivers Implement Them • Drivers Read/Write to Process Address Space • Drivers Use Other Kernel Functions For: • Device Allocation • Resource (E.G., Memory) Allocation • Scheduling • Etc. (Varies From OS to OS) • Reconfigurable Device Driver - Add Driver to OS without Recompiling (May Need to Restart)

26. Reconfigurable Device Drivers • Indirect Reference Table (IRT) for Driver Entry • Installation of Driver Creates Entry in IRT • Data Driven Reconfiguration Operating System Interface IRT open(){…} Driver for Device j read(){…} Entry Points for Device j etc. Other Kernel Services Driver/Kernel Interface

27. Coordinating the I/O Operation Process read(...); Driver read(...){ ... read_request() wait_for_done(); return; } while(1) { ask_for_work(); do_the_work(); } Controller (HW)

28. NT Device Drivers • API Model is the Same As a File • Extend Device Management by Adding Modules to the Stream • Device Driver is Invoked Via an Interrupt Request Packet (IRP) • IRP Can Come From Another Stream Module • IRP Can Come From the OS • Driver Must Respond to Minimum Set of IRPs • See Part I of Notes

29. NT Driver Organization

30. Device Management Considerations • What is Impact of Media on Device Drivers? • Consider Based on Device Classification • Serial Devices • Bit Serial Transmission • Terminals, Printers, Modems, etc. • Sequentially Access Storage Devices • Persistent Storage - Sequential Order of Access • Block Access, e.g., Magnetic Tapes • Randomly Accessed Devices • Persistent Storage - Arbitrary Order of Access • Block Access, e.g., Hard Disk, Optical Disk, DVD • All Prevalent on Contemporary Computers

31. Serial Communication Device Universal Asynchronous Receiver Transmitter • Driver • Set UART Parameters • read/write Opers. • Interrupt Hander • UART • Parity • Bytes/Bit • Etc. Controller • RS-232 • 9-pin Connector • 4-Wires • Bit Serial • Etc. Modem

32. Sequentially Access Storage Devices • Persistent Storage in Computer • Block-Oriented Utilization of Device • Block Access to Optimize Transfer • Block Size is Device/Controller Dependent • Linear/Non-Linear Byte Orders with Blocks • Classic Sequential Device: Magnetic Tape • Contain Nine Tracks (1 Byte + Parity) • Nine Read/Write Heads • Move Tape Across R/W Heads • Seeking Possible But Time Consuming • Still Used for Backup Medium

33. Randomly Accessed Storage Devices • Popular Media (Hard Drives, CDs, DVDs, etc.) • Access to Information in Any Order • Sequential Access Not Typically Supported or Needed, Since “Files” Not Stored Sequentially • Recall, Disk Defragmentation on PC Platform • Key Concepts … • Platter • Track • Sector • Cylinder • Read/Write Heads

34. Rotating Storage Track R/W Heads Platters Sector Cylinder Top View of a Surface Note: Parallel Read/Write Drives Activate All Heads Simultaneously

35. MS Disk Geometry

36. Disk Characteristics and Access • Disks Typically DMA Devices • Transfer Time: Time to Copy Bits From Disk Surface to Primary Memory • Disk Latency Time: • Rotational Delay Waiting for Proper Sector to Rotate Under R/W Head • Rotate to Next Sector to Process Next Request • Disk Seek Time: • Delay While R/W Head Moves to the Destination Track/Cylinder • Move Head In/Out to Seek Next Track/Cylinder • Access Time = Seek (In/Out) + Latency (Around) + Transfer (Bytes)

37. Optimizing Seek TimeStrategies for Disk Access • Multiprogramming on I/O-Bound Programs • Set of Processes Waiting for Disk • Each Process has One or More I/O Requests • Seek Time Dominates Access Time • What Order Should Requests be Processed? • Goal: Minimize Seek Time Across the Set • Assumptions (Simplify to Tracks Only): • Tracks 0:99 • One Head at Track 75 • Requests for 23, 87, 36, 93, 66 • First Come First Serve (FCFS) • 52+ 64 + 51 + 57 + 27 = 251 Steps

38. Optimizing Seek TimeStrategies for Disk Access • Tracks 0:99, Head 75, Requests 23, 87, 36, 93, 66 • Shortest Seek Time First (SSTF) • Reorder to (75), 66, 87, 93, 36, 23 • 11 + 21 + 6 + 57 + 13 = 107 steps • Scan Algorithm (Start at One End and Move in One Direction, Reordering as Needed): • (75), 87, 93, 99, 66, 36, 23 • 12 + 6 + 6 + 33 + 30 + 13 = 100 steps • Look Algorithm (Scan But Stop at Highest Track of Current Request): • (75), 87, 93, 66, 36, 23 • 12 + 6 + 27 + 30 + 13 = 87 steps

39. Optimizing Seek TimeStrategies for Disk Access • Tracks 0:99, Head 75, Requests 23, 87, 36, 93, 66 • Circular Scan (Goes from Current Position to 99 and then Resets at 0 - Adds Reset Time): • (75), 87, 93, 99, 23, 36, 66 • 12 + 6 + 6 + home + 23 + 13 + 30 = 90 + home • Circular Look (Goes from Current Position to Highest and then Resets at 0 - Adds Reset Time): • (75), 87, 93, 23, 36, 66 • 12 + 6 + home + 23 + 13 + 30 = 84 + home

40. Concluding Remarks/Looking Ahead • Examination of Capabilities and Classes of Drivers • Drivers Concerned with Performance of OS • Drivers Impact CPU/Memory Utilization • Open Systems + Home Market Has Dramatically Changed Devices and Usage • Interesting Exercise 5 in Section 5.6 • Impact of Double Buffering on Process • What if I/O Bound Process Requests Characters at Higher Rate than Device Produces? • What if CPU Bound Process Rarely Requests Characters? • Looking Ahead to Process Management and Scheduling