Silberschatz, Galvin and Gagne 2002 13.1 Operating System Concepts I/O Hardware Incredible variety of I/O devices

Silberschatz, Galvin and Gagne 200213.1Operating System Concepts

I/O Hardware

Incredible variety of I/O devices


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


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


A Kernel I/O Structure


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


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


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


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


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


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


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


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


Six Step Process to Perform DMA Transfer


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


Network Devices

Approaches vary widely Pipes FIFOs Streams Queues Mailboxes

Socket interface Separates network protocol from network operation Includes select functionality


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


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


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


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


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).

Documents

Silberschatz, Galvin and Gagne 2002 13.1 Operating System Concepts I/O Hardware Incredible variety of I/O devices