Input/Output Systems - NMT Computer Science and …cs325/spring2013/Lec18-IOManagement.pdf · CSE325 Principles of Operating Systems Input/Output Systems ... 4/2/13 CSE325 - I/O Systems

CSE325 Principles of Operating Systems

Input/Output Systems

David P. Duggan dduggan@sandia.gov

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