Transcript I/O Subsystems - Southern Oregon University

Hardware
• Definitions
– Port: Point of connection
– Bus: Interface
• Daisy Chain (A=>B=>…=>X)
• Shared Direct Device Access
– Controller: Device Electronics
– Registers: Device Storage for CPU
to device communication
– Handshakes: signals sent between
devices and the CPU through
shared memory or privileged I/O
instructions
• Issue (many devices & manufactures)
• Solutions
– Standard interfaces
– Uniform drivers for device groups
– Manufacturer provided drivers
Device addresses for automatic probes
CPU Device Control
• Privileged I/O instructions control devices
– Interface with device command-ready, busy, and error status registers
• Direct memory I/O instructions
– Ties devices to memory locations
• Memory-mapped I/O
– Reserved memory addresses control a device (E.g.: monitor display)
• Simple Polling interface
– Useful if device response is almost instantaneous (busy-wait)
WHILE command-ready-register = device-not-ready THEN spin
Issue send or receive command
WHILE device is busy THEN spin (This is a busy wait loop)
IF error and retry-count not expired THEN restart the command
RETURN I/O complete
Programmed IO
• I/O raises the CPU Interrupt request line
• At next instruction, the Interrupt occurs, and the CPU state saved
• The Interrupt vector directs interrupts to the correct handler
– Interrupt chaining ties multiple devices to a single vector entry
– Some interrupts can be masked based on priority
• Traps are software triggered interrupts
Direct Memory Access (DMA)
•
•
•
•
Used to avoid programmed I/O for large data transfers from fast devices
Requires a DMA controller enabling devices to directly access memory
CPU cycles are stolen for each memory reference
The driver gives the DMA controller chains of addresses and lengths
I/O Sub-system
Purpose: Abstract, Encapsulate, and Layer
Device-drivers: Encapsulate controller differences from kernel
Device Categories
I/O Subsystem Structure
• Note: Some specialized devices have unique interfaces and drivers
Device Categories by Speed
Kernel Data Structures
• Kernel maintains system-wide I/O components table
• Kernel maintains free, used, “dirty” buffers in complex data structures
• I/O Wait queues and cache buffering
Device-status Table
Application API
• Block devices include disk drives
– Commands include read, write, seek
– Raw I/O or file-system access
– Memory-mapped byte streams using virtual memory facilities
• Character devices (keyboards, mice, serial ports)
– Commands include get, put
– Libraries layered on top allow line editing (backspace etc.)
• Network devices
– Incorporates protocol, flow control, and pipelining
– Separates network protocol from network operation
– Includes select functionality (socket port numbers)
• Clocks and Timers for current time and elapsed time
– Course grain regular interval interrupts
– Programmable non-interruptible timers for fine grain resolution
System Call to Perform I/O
Categories of OS calls
• Blocking - process suspended until I/O completed
– Easy to use and understand
– Insufficient for some needs
• Non-blocking - I/O call returns as much as available
– User interface, data copy (OS 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
• Direct Application control
– ioctl (on UNIX) allows applications to directly control devices
– Driver testing
Additional OS I/O Subsystem Services
• Caching - fast memory access to recently accessed data
– Always just a copy
– Significant performance impact
• Spooling - hold output for a device
– If device can serve only one request at a time
– i.e., Printing
• Exclusive device reservation
•
•
•
•
– System calls for allocation and de-allocation
– Deadlocks are possible
Scheduling - Ordering the I/O requests in the per-device queue
– Some OSs try fairness
Buffering - store data in OS buffers during transfers
– To cope with device speed or transfer size mismatches
– To maintain “copy semantics”, and dirty buffers.
Fault processing: Recovery through retry operations, error logs
Miscellaneous: Pipes, FIFOs, packet handling, streams, queues, mailboxes
Flow of an
I/O
Request
• Consider request
to read a file
– What device?
– Name translation
– Copy between
application and
kernel buffer
– Change process
status to ready
Streams
• STREAM – flow from source to
sink (process <--> device)
– Full-duplex: flow in both
directions
– Stream head interfaces
with the user process
– Stream tail interfaces with
the device
– Stream wrappers enable
data manipulation (filtering)
at each level, which contain
their own read/write
queuing capabilities
• Implementation
– Message passing between
adjacent queues
– Multiple copies operations
will increase overhead
Performance
• Potential bottlenecks:
– CPU device processing
– Context switches after
processing interrupts
– Copying between OS and
user buffers
– Routing network traffic
• Performance improvements
– Reduce context switches
– Minimize data copying
– Minimize interrupts and
reduce latency by using
large transfers, smart
controllers, DMA
– Balance CPU, memory,
bus, and I/O contention for
highest throughput
I/O System flow illustrating bottlenecks
Incorporate of new Devices
Where should the device handling code go?