Title: Chapter 5: Device Management
1Chapter 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_at_engr.uconn.edu http//www.engr.uconn.edu/st
eve (860) 486 - 4818
These slides have been modified from a set
of originals by Dr. Gary Nutt.
2Purpose 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
3Device 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
- Well Review and See Examples of Each
4Device Management Organization
- 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
5Direct 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 Controllers
Command Register - Starts the Device (HW) - Driver Checks Status Register - Done Yet?
- Driver Copies Controllers Data Registers into
Applicationss Process Space
6Direct I/O with Polling (Read)
- 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?
7Interrupt 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 Controllers Data Registers into User
Space - Returns Control to Application Process
8Interrupt Driven I/O (Read)
read(device, )
Data
System Interface
Device Status Table
Device Handler
read driver
write driver
Interrupt Handler
Hardware Interface
Command
Status
Data
Device Controller
9Observations
- Viewpoint from Application Program
- Procedure Call to Read
- In Polling, Read Waits in Driver
- In Interrupt, Read Waits in Application
- Whats 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
10Overlapping CPU Execution with I/O
. . . startRead(dev_I, d, x) . .
. while(stillReading()) y f(x) . . .
. . . read(dev_I,d,x) y f(x) . . .
Logically Equivalent
- Read Must Wait for Completion
- Else, yf(x)Could Use Old Value of x in Call
11Memory 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
12Addressing 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
13Direct Memory Access (DMA)
- 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
14Direct Memory AccessTraditional I/O vs. DMA
- Whats 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
15I/O - CPU Overlap
t1
t2
t3
t4
Overlapping Appl 1s I/O with Appl 2
t1
t2
t3
t4
t5
t6
t7
t8
t9
Overlapping Appl CPU with its own I/O
16Buffering
- 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?
17Hardware Buffering of Modem Character Device
- Device (HW) Buffers Next Character to Controller
(HW) as Process Reads Prior Character - Overlap of Read with CPU Execution
18Double 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
B
A
Driver
Controller
B
A
Hardware
Device
19Double Buffering in the Driver
Process
Process
B
A
B
A
Driver
Controller
Controller
B
A
B
A
Hardware
Device
Device
20A Ring Buffer
To data consumer
Buffer i
Buffer j
From Data Producer
- 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
21Program 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
22Device 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
23Application 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?
24Sample 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
25The 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)
26Reconfigurable 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
27Coordinating the I/O Operation
Process
read(...)
Driver
read(...) ... read_request()
wait_for_done() return
while(1) ask_for_work() do_the_work()
Controller (HW)
28NT 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
29NT Driver Organization
30Device 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
31Serial 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
32Sequentially 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
33Randomly 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
34Rotating Storage
Track
R/W Heads
Platters
Sector
Cylinder
Top View of a Surface
Note Parallel Read/Write Drives Activate All
Heads Simultaneously
35MS Disk Geometry
36Disk 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)
37Optimizing 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 099
- One Head at Track 75
- Requests for 23, 87, 36, 93, 66
- First Come First Serve (FCFS)
- 52 64 51 57 27 251 Steps
38Optimizing Seek TimeStrategies for Disk Access
- Tracks 099, 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
39Optimizing Seek TimeStrategies for Disk Access
- Tracks 099, 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
40Concluding 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