Incredible variety of I/O devices
Operating System Concepts 13.1
Silberschatz, Galvin and Gagne
2002
Devices vary in many dimensions
Direction
Read, Write, Read-Write
Character, Block
Speed
Latency, Transfer rate, Delay between operations
Access
Sequential, Random
Sharing
Sharable, Dedicated
IO subsystem reduces perceived differences for apps, and optimizes performances for apps
13.2
Silberschatz, Galvin and Gagne
2002 Operating System Concepts
Common concepts (provide abstraction)
Port (serial, parallel, ethernet)
Bus (daisy chain or shared direct access)
Controller (host adapter operates ports/bus/device)
See my picture
Operating System Concepts 13.3
Silberschatz, Galvin and Gagne
2002
Operating System Concepts 13.4
Silberschatz, Galvin and Gagne
2002
I/O system calls encapsulate device behaviors in generic classes
Device-driver layer hides differences among I/O controllers from kernel
Makes OS independent of the IO hardware
Provided by the device/controller manufacturers
DDs are part of the OS (not processes) usually
OS defines interface to DDs
Non-standard across OSs => device manufacturers have to provide a DD for each OS (bugger)
Applications normally reach the DDs via the OS
Escape entry (e.g., ioctl) allows more direct access
13.5
Silberschatz, Galvin and Gagne
2002 Operating System Concepts
Scheduling
To maximize performance
I/O request ordering via per-device queue
Some OSs try fairness
Device reservation - provides exclusive access to a device (e.g., in VMS)
System calls for allocation and deallocation
Wait for device on call, e.g., NT
Watch out for deadlock
13.6
Silberschatz, Galvin and Gagne
2002 Operating System Concepts
Buffering - store data in memory while transferring between devices
To cope with device speed mismatch
E.g., modem to disk (x1000)
Double buffering
To cope with device transfer size mismatch
E.g., keyboard to disk
Collating network packets
To maintain “copy semantics”
Caching - fast memory holding copy of data
Always just a copy (as opposed to a buffer)
Often implemented in buffer system
Key to performance
Silberschatz, Galvin and Gagne
2002 Operating System Concepts 13.7
OS can recover from transient failures E.g., disk read, device unavailable, network failures
Permanent failures
OS can make devices unavailable
Need operator intervention
System calls return an error code when I/O fails
System error logs hold problem reports
More detailed information than return values
HW diagnostic information, e.g., from SCSI controllers
13.8
Silberschatz, Galvin and Gagne
2002 Operating System Concepts
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
E.g., user interface, data copy (buffered I/O)
Can be 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
13.9
Silberschatz, Galvin and Gagne
2002 Operating System Concepts
Request may be satisfied immediately, e.g., in cache
The request for the DD may have to be queued
CPU runs async with device
DD waits in sync with device
It’s blocking I/O.
Nonblocking I/O always “can satisfy request”
Asynchronous I/O does not block the process
Direct I/O instructions
Placed in registers
Status, control, data-in, data-out
Memory-mapped I/O
Maps registers onto RAM
Can be faster than I/O instructions
Silberschatz, Galvin and Gagne
2002 Operating System Concepts 13.10
Synchronous communication
Controller waits for command-ready bit in controller status register bit to be set
Host waits for busy bit in controller status register to be clear
(initially it is clear)
Host places command in command register, and any required data in data register
Host sets command-ready bit, and waits for it to clear
Controller notices command-ready bit, sets busy bit, clears command-ready bit.
Host loops waiting for busy bit to clear, while controller does IO
Controller clears busy and command-ready bits, and loops
Vantages
Done once for each byte
Wasteful of CPU time if IO takes long
Can use offboard CPU, e.g., in SCSI controller
Useful for fast data streams
Silberschatz, Galvin and Gagne
2002 Operating System Concepts 13.11
Used to avoid programmed I/O for large data movement
If device transmits close to memory speeds, little time is left for processing
Requires DMA controller
Bypasses CPU to transfer data directly between I/O device and memory
DMA controller steals RAM cycles from CPU
Operating System Concepts 13.12
Silberschatz, Galvin and Gagne
2002
Operating System Concepts 13.13
Silberschatz, Galvin and Gagne
2002
Spooling - hold output for a device
If device can serve only one request at a time
Provides asynchronous I/O
i.e., Printing and the lpd
Operating System Concepts 13.14
Silberschatz, Galvin and Gagne
2002
Approaches vary widely
Pipes
FIFOs
Streams
Queues
Mailboxes
Socket interface
Separates network protocol from network operation
Includes select functionality
13.15
Silberschatz, Galvin and Gagne
2002 Operating System Concepts
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, e.g., NT, Nachos, nu
Operating System Concepts 13.16
Silberschatz, Galvin and Gagne
2002
Cooked interfaces are buffered
Block buffers
C-lists
Raw interfaces are unbuffered
Devices have major and minor device numbers.
Major number used as index into array of DD entry points
Direct access via ioctl() and /dev files
Operating System Concepts 13.17
Silberschatz, Galvin and Gagne
2002
Consist of buffer headers, each of which can point to a piece of physical memory, and contain a device number and a block number on the device.
The buffer headers for blocks not currently in use are kept in several linked lists:
Buffers not recently used, or with invalid contents (AGE list).
Buffers recently used, linked in LRU order (LRU list).
Buffers with no associated physical memory (EMPTY list).
On read the cache is searched.
If the block is found it is used - no I/O transfer is necessary.
If it is not found, a buffer is chosen from the AGE list, or the
LRU list if AGE is empty.
On write, if the block is in the cache, then write and set dirty bit
Dirty blocks are output by regular sync()
Blocks may be fragmented, and headers are taken from EMPTY
Operating System Concepts 13.18
Silberschatz, Galvin and Gagne
2002
The raw device interface — unlike the block interface, it bypasses the block buffer cache.
Each disk driver maintains a queue of pending transfers:
whether it is a read or a write
a main memory address for the transfer a device address for the transfer
a transfer size
Can use user memory for a transfer record
Operating System Concepts 13.19
Silberschatz, Galvin and Gagne
2002
Terminal drivers use a character buffering system which involves keeping small blocks of characters in linked lists.
A write system call to a terminal enqueues characters on a list for the device. An initial transfer is started, and interrupts cause dequeueing of characters and further transfers, i.e., it’s asynchronous
Input is similarly interrupt driven.
It is also possible to have the device driver bypass the canonical queue and return characters directly from the raw queue — raw mode (used by full-screen editors and other programs that need to react to every keystroke).
13.20
Silberschatz, Galvin and Gagne
2002 Operating System Concepts