input/output systems - nmt computer science and …cs325/spring2013/lec18-iomanagement.pdf ·...
TRANSCRIPT
CSE325 Principles of Operating Systems
Input/Output Systems
David P. Duggan [email protected]
April 2, 2013
4/2/13 CSE325 - I/O Systems 2
Input/Output Devices
Input Device Processor
Output Device
4/2/13 CSE325 - I/O Systems 3
Why we care about I/O? • CPU Performance: 50% to 100% improvement per year • I/O system performance limited by mechanical delays
< 5% per year (IO per sec or MB per sec)
• Amdahl's Law: system speed-up limited by the slowest part!
10% IO & 10x CPU ⇒ 5x Performance (lose 50%) 10% IO & 100x CPU ⇒ 10x Performance (lose 90%)
• I/O bottleneck: Diminishing fraction of time in CPU Diminishing value of faster CPUs
4/2/13 CSE325 - I/O Systems 4
I/O Systems
4/2/13 CSE325 - I/O Systems 5
A Typical PC Motherboard
4/2/13 CSE325 - I/O Systems 6
A Typical PC Bus Structure
4/2/13 CSE325 - I/O Systems 7
Device I/O Port Locations on PCs (partial)
4/2/13 CSE325 - I/O Systems 8
The Device Driver Interface
Device Interface
… write(…); …
Terminal Driver
Printer Driver
Disk Driver
Terminal Controller
Printer Controller
Disk Controller
Abstract Software Interfaces
4/2/13 9
Device Management Organization Application
Process
File Manager
Device Controller
Command Status Data
Hardware Interface
System Interface
Device-Independent Device-Dependent
Why 2 layers?
4/2/13 10
A Kernel I/O Structure
4/2/13 11
Device Independent Function Call
funci(…)
Trap Table
dev_func_i(devID, …) { // Processing common to all devices … switch(devID) { case dev0: dev0_func_i(…);
break; case dev1: dev1_func_i(…);
break; … case devM: devM_func_i(…);
break; }; // Processing common to all devices … }
4/2/13 12
System Call Interface • Functions available to application programs • Abstract all devices (and files) to a few interfaces • Make interfaces as similar as possible
– Block vs character – Sequential vs direct access
• Device driver implements functions (one entry point per API function)
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
4/2/13 13
Operation of a Device
Variable x Register
Data on device
. . . read(dev_I, “%d”, x); y = f(x) . . .
Device dev_I Memory CPU
. . . startRead(dev_I, “%d”, x); . . . While(stillReading()) ; y = f(x) . . .
Problem?
4/2/13 CSE325 - I/O Systems 14
Overlapping Processing and I/O
App 1 App 2 I/O Ctlr
t1 t2 t3 t4
4/2/13 CSE325 - I/O Systems 15
Overlapping CPU-Controller Operations in a Process
App
I/O Ctlr
t1 t2 t3 t4 t5 t6 t7 t8 t9
4/2/13 CSE325 - I/O Systems 16
Polling I/O Read Operation read(device, …);
Data
Device Controller
Command Status Data
read function
write function
1
2 3 4
5
Hardware Interface
System Interface
Is there a performance problem? Low CPU utilization
4/2/13 CSE325 - I/O Systems 17
Interrupt-driven I/O Operation read(device, …);
Data
Device Controller
Command Status Data
read driver
write driver
1
2 3
4
5 Hardware Interface
System Interface Device Status Table
Device Handler
Interrupt Handler
6
7
8a
8b 9
4/2/13 CSE325 - I/O Systems 18
Handling Interrupts
int read(…) { // Prepare for I/O save_state(J); out dev# // Done (no return) }
Device driver J
Device Controller
Interrupt Handler
void dev_handler(…) { get_state(J); //Cleanup after op signal(dev[j]); return_from_sys_call(); }
Device interrupt handler J
J
Device status table
4/2/13 CSE325 - I/O Systems 19
Handling Interrupts(2)
int read(…) { … out dev# // Return after interrupt wait(dev[J}); return_from_sys_call(); }
Device driver J
Device Controller
Interrupt Handler
void dev_handler(…) { //Cleanup after op signal(dev[j]); }
Device interrupt handler J
4/2/13 20
Intel Pentium Processor Event-Vector Table
4/2/13 CSE325 - I/O Systems 21
Direct Memory Access • Used to avoid programmed I/O for large data
movement
• Requires DMA controller
• Bypasses CPU, transfers data directly between I/O device and memory
4/2/13 CSE325 - I/O Systems 22
Six Step Process to Perform DMA Transfer
4/2/13 CSE325 - I/O Systems 23
Characteristics of I/O Devices
4/2/13 CSE325 - I/O Systems 24
Block and Character Devices • Block devices, e.g., disk drives
– Commands include read, write, seek – Raw I/O or file-system access – Memory-mapped file access possible
• Character devices, e.g., keyboards, mice, serial ports – Commands include get, put – Libraries layered on top allow line editing
4/2/13 CSE325 - I/O Systems 25
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 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 – Can be difficult to use – I/O subsystem signals process when I/O completed
4/2/13 CSE325 - I/O Systems 26
Two I/O Methods
Synchronous" Asynchronous"
4/2/13 CSE325 - I/O Systems 27
Kernel I/O Subsystem • Scheduling
– Some I/O requests ordered via per-device queue – Some OSs try fairness – Priority of VM subsystem over app requests
• Buffering - store data in memory while transferring between devices – To cope with device speed mismatch – To cope with device transfer size mismatch – To maintain “copy semantics”
4/2/13 CSE325 - I/O Systems 28
Device-status Table
4/2/13 CSE325 - I/O Systems 29
Error Handling • OS must 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
4/2/13 CSE325 - I/O Systems 30
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
Database?
4/2/13 31
System Call Use to Perform I/O
4/2/13 CSE325 - I/O Systems 32
Kernel Data Structures • 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
4/2/13 CSE325 - I/O Systems 33
UNIX I/O Kernel Structure
4/2/13 CSE325 - I/O Systems 34
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
4/2/13 CSE325 - I/O Systems 35
Life Cycle of An I/O Request
4/2/13 CSE325 - I/O Systems 36
Performance • I/O a major factor in system performance:
– Demands CPU to execute device driver, kernel I/O
code – Context switches due to interrupts – Data copying – Network traffic especially stressful
4/2/13 CSE325 - I/O Systems 37
Improving Performance • 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
4/2/13 38
Hardware Buffering Process
Controller
Data
Device
Process
Controller
B
Device
A
Process
Controller
B
Device
A
Unbuffered Process reads bi-1 Controller reads bi
Process reads bi Controller reads bi+1