Download IOSystems

I/O Hardware
 Incredible variety of I/O devices
Operating System Concepts
13.1
Silberschatz, Galvin and Gagne 2002
I/O Hardware
 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
Operating System Concepts
13.2
Silberschatz, Galvin and Gagne 2002
I/O Hardware
 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
A Kernel I/O Structure
Operating System Concepts
13.4
Silberschatz, Galvin and Gagne 2002
Application I/O Interface
 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
Operating System Concepts
13.5
Silberschatz, Galvin and Gagne 2002
Kernel I/O Subsystem
 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
Operating System Concepts
13.6
Silberschatz, Galvin and Gagne 2002
Kernel I/O Subsystem
 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
Operating System Concepts
13.7
Silberschatz, Galvin and Gagne 2002
Error Handling
 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
Operating System Concepts
13.8
Silberschatz, Galvin and Gagne 2002
Blocking and Non-blocking I/O
 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
Operating System Concepts
13.9
Silberschatz, Galvin and Gagne 2002
Life Cycle of An I/O Request
 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.
 Non-blocking 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
Operating System Concepts
13.10
Silberschatz, Galvin and Gagne 2002
An Alternative - Polling
 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
Operating System Concepts
13.11
Silberschatz, Galvin and Gagne 2002
Direct Memory Access
 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
Six Step Process to Perform DMA Transfer
Operating System Concepts
13.13
Silberschatz, Galvin and Gagne 2002
Spooling
 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
Network Devices
 Approaches vary widely
 Pipes
 FIFOs
 Streams
 Queues
 Mailboxes
 Socket interface
 Separates network protocol from network operation
 Includes select functionality
Operating System Concepts
13.15
Silberschatz, Galvin and Gagne 2002
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, e.g., NT, Nachos, nu
Operating System Concepts
13.16
Silberschatz, Galvin and Gagne 2002
4.3 BSD Kernel I/O Structure
 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
Block Buffer Cache
 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
Raw Device Interfaces
 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
C-Lists
 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).
Operating System Concepts
13.20
Silberschatz, Galvin and Gagne 2002