Download pdf - Ch13 Annotated

Page 1: Ch13 Annotated

8/10/2019 Ch13 Annotated 1/30

Silberschatz, Galvin and Gagne 2002 13.1Operating System Concepts

Chapter 13: I/O Systems- 6th ed 

I/O Hardware Application I/O Interface

Kernel I/O Subsystem

Transforming I/O Requests to Hardware Operations



Review Chapters 2 and 3, and instructors notes on:

“Interrupt schemes and DMA” 

This chapter gives more focus to these chapters and topics.

Instructor‟s annotations in blue Updated 12/5/03

Page 2: Ch13 Annotated

8/10/2019 Ch13 Annotated 2/30

Silberschatz, Galvin and Gagne 2002 13.2Operating System Concepts

I/O Hardware

Incredible variety of I/O devices Common concepts

Port - basic interface to CPU - status, control, data 

Bus (daisy chain or shared direct access) - main andspecialized local (ex: PCI for main and SCSI for disks)

Controller (host adapter) - HW interface between Deviceand Bus - an adapter card or mother board moduleController has special purposes registers (commands,etc.) which when written to causes actions to take place- may be memory mapped

I/O instructions control devices - ex: in, out for Intel 

Devices have addresses, used by

Direct I/O instructions - uses I/O instructions 

Memory-mapped I/O - uses memory instructions 

Page 3: Ch13 Annotated

8/10/2019 Ch13 Annotated 3/30

Silberschatz, Galvin and Gagne 2002 13.3Operating System Concepts

A Typical PC Bus Structure

Page 4: Ch13 Annotated

8/10/2019 Ch13 Annotated 4/30

Silberschatz, Galvin and Gagne 2002 13.4Operating System Concepts

Device I/O Port Locations on PCs (partial)

Various ranges for a device includes both control and data ports 

Page 5: Ch13 Annotated

8/10/2019 Ch13 Annotated 5/30

Silberschatz, Galvin and Gagne 2002 13.5Operating System Concepts


Handshaking  Determines state of device




Busy-wait cycle to wait for I/O from deviceWhen not busy - set data in data port, set commandin control port and let „er rip 

Not desirable if excessive - since it is a busy wait

which ties up CPU & interferes with productive work 

Remember CS220 LABs 

Page 6: Ch13 Annotated

8/10/2019 Ch13 Annotated 6/30

Silberschatz, Galvin and Gagne 2002 13.6Operating System Concepts


CPU Interrupt request line (IRQ) triggered by I/O device

Interrupt handler receives interrupts

Maskable to ignore or delay some interrupts

Interrupt vector to dispatch interrupt to correct handler

Based on priority

Some unmaskable Interrupt mechanism also used for exceptions

Application can go away after I/O request, but is tilresponsible for transferring data to memory when itbecomes available from the device.

Can have “nested” interrupts (with Priorities)  See Instructors notes: “Use of Interrupts and DMA” 

Soft interrupts or “traps” generated from OS in

system calls. 

Page 7: Ch13 Annotated

8/10/2019 Ch13 Annotated 7/30Silberschatz, Galvin and Gagne 2002 13.7Operating System Concepts

Interrupt-Driven I/O Cycle

Go away & do

Something else ==> 

Page 8: Ch13 Annotated

8/10/2019 Ch13 Annotated 8/30Silberschatz, Galvin and Gagne 2002 13.8Operating System Concepts

Intel Pentium Processor Event-Vector Table

Interrupts 0-31 are non-maskable - cannot be disabled 

Page 9: Ch13 Annotated

8/10/2019 Ch13 Annotated 9/30Silberschatz, Galvin and Gagne 2002 13.9Operating System Concepts

Direct Memory Access

With pure interrupt scheme, CPU was stillresponsible for transferring data from controller to

memory (on interrupt) when device mad it available.

Now DMA will do this - all CPU has to do is set upDMA and user the data when the DMA-completeinterrupt arrives. … Interrupts still used - but only to

signal DMA Complete. 

Used to avoid programmed I/O for large data movement

Requires DMA controller

Bypasses CPU to transfer data directly between I/Odevice and memory

Cycle stealing: interference with CPU memoryinstructions during DMA transfer. - DMA takespriority - CPU pauses on memory part of word.

Page 10: Ch13 Annotated

8/10/2019 Ch13 Annotated 10/30Silberschatz, Galvin and Gagne 2002 13.10Operating System Concepts

Six Step Process to Perform DMA Transfer

Page 11: Ch13 Annotated

8/10/2019 Ch13 Annotated 11/30Silberschatz, Galvin and Gagne 2002 13.11Operating System Concepts

Application I/O Interface The OS software interface to the I/O devices (an API

to the programmer) 

Attempts to abstract the characteristics of the manyI/o devices into a few general classes.

I/O “system calls” encapsulate  device behaviors ingeneric classes

Device-driver layer hides differences among I/O

controllers from kernel

Devices vary in many dimensions

Character-stream or block

 units for data transfer bytes vs blocks 

Sequential or random-access - access methods

Synchronous (predictable response times) vsasynchronous (unpredictable response times)

Sharable or dedicated - implications on deadlock 

Speed of operation - device/software issue 

read-write, read only, or write only - permissions

Page 12: Ch13 Annotated

8/10/2019 Ch13 Annotated 12/30Silberschatz, Galvin and Gagne 2002 13.12Operating System Concepts

A Kernel I/O Structure

System calls ==>… “user” API


Example: ioctl(…)

generic call(roll your own)in UNIX (p. 468),and other morespecificcommands or callsopen, read, ... 

Fig. 13.6

Page 13: Ch13 Annotated

8/10/2019 Ch13 Annotated 13/30Silberschatz, Galvin and Gagne 2002 13.13Operating System Concepts

Characteristics of I/O Devices

Device driver must deal with these at a low level 

Use of I/O buffering 

Page 14: Ch13 Annotated

8/10/2019 Ch13 Annotated 14/30Silberschatz, Galvin and Gagne 2002 13.14Operating System Concepts

Block and Character Devices

Block devices include disk drives

example sectors or sector clusters on a disk 

Commands /calls include read, write, seek 

Access is typically through a file-system interface 

Raw I/O or file-system access - “binary xfr” of file data - interpretationis in application (personality of file lost)

Memory-mapped (to VM) file access possible - use memory instructionsrather than I/O instructions - very efficient (ex: swap space for disk).

Device driver xfr‟s blocks at a time - as in paging

DMA transfer is block oriented 

Character devices include keyboards, mice, serial ports

Device driver xfr‟s byte at a time 

Commands include get, put - character at a time 

Libraries layered on top allow line editing - ex: keyboard input

could be beefed up to use a line at a time (buffering)

Block & character devices also determine the two general devicedriver catagories

Page 15: Ch13 Annotated

8/10/2019 Ch13 Annotated 15/30

Silberschatz, Galvin and Gagne 2002 13.15Operating System Concepts

Network Devices

Varying enough from block and character to have owninterface - OS makes network device interface distinctfrom disk interface - due to significant differencesbetween the two 

Unix and Windows NT/9i  /2000 include socket interface

Separates network protocol from network operation

Encapsulates  details of various network devices forapplication … analogous to a file and the disk??? 

Includes select functionality - used to manage and access

sockets - returns info on packets waiting or ability to acceptpackets - avoids polling

Approaches vary widely (pipes, FIFOs, streams, queues,mailboxes) … you saw some of these! 

Page 16: Ch13 Annotated

8/10/2019 Ch13 Annotated 16/30

Silberschatz, Galvin and Gagne 2002 13.16Operating System Concepts

Clocks and Timers

Provide current time, elapsed time, timer

If programmable, interval time used for timings, periodicinterrupts

ioctl (on UNIX) covers odd aspects of I/O such asclocks and timers - a back door for device driverwriters (roll your own). Can implement “secret” calls

which may not be documented in a users orprogramming manual 

Page 17: Ch13 Annotated

8/10/2019 Ch13 Annotated 17/30

Silberschatz, Galvin and Gagne 2002 13.17Operating System Concepts

Blocking and Nonblocking I/O Blocking - process (making the request blocks - lets other process

execute)  suspended until I/O completed

Easy to use and understand Insufficient for some needs

multi-threading - depends on role of OS in thread management 

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 - ex: read a “small”

portion of a file very quickly, use it, and go back for more, ex:displaying video “continuously from a disk”

Asynchronous - process (making the asynch request)  runs while I/Oexecutes

Difficult to use - can it continue without the results of the I/O? 

I/O subsystem signals process when I/O completed - via interrupt (soft),or setting of shared variable which is periodically tasted.

Page 18: Ch13 Annotated

8/10/2019 Ch13 Annotated 18/30

Silberschatz, Galvin and Gagne 2002 13.18Operating System Concepts

Kernel I/O Subsystem See A Kernel I/O Structure slide - Fig 13.6 


Some I/O request ordering via per-device queue

Some OSs try fairness

Buffering - store data in memory while transferring between devices

To cope with device speed mismatch - de-couples application from

device action To cope with device transfer size mismatch

To maintain “copy semantics” - guarantee that the version of datawritten to device from a buffer is identical to that which was there

at the time of the “write call”  - even if on return of the system call,

the user modifies buffer - OS copies data to kernel buffer beforereturning control to user.

Double or “ping-pong” buffers - write in one and read fromanother - decouples devices and applications… idea can be extended to multiple buffers accesses in a circular


Page 19: Ch13 Annotated

8/10/2019 Ch13 Annotated 19/30

Silberschatz, Galvin and Gagne 2002 13.19Operating System Concepts

Sun Enterprise 6000 Device-Transfer Rates

Page 20: Ch13 Annotated

8/10/2019 Ch13 Annotated 20/30

Silberschatz, Galvin and Gagne 2002 13.20Operating System Concepts

Kernel I/O Subsystem - (continued) 

Caching - fast memory holding copy  of data

Always just a copy

Key to performance

How does this differ from a buffer? 

Spooling - a buffer  holding output /(input too) for a device

If device can serve only one request at a time

Avoids queuing applications making requests.

Data from an application is saved in a unique file associatedwith the application AND the particular request. Could besaved in files on a disk, or in memory. 

Example: Printing

Device reservation - provides exclusive access to a device

System calls for allocation and deallocation

Watch out for deadlock - why? 

Page 21: Ch13 Annotated

8/10/2019 Ch13 Annotated 21/30

Silberschatz, Galvin and Gagne 2002 13.21Operating System Concepts

Error Handling

OS can recover from disk read, device unavailable,transient write failures

Most return an error number or code when I/O requestfails

System error logs hold problem reports

CRC checks - especially over network transfers of alot of data, for example video in real time. 

Page 22: Ch13 Annotated

8/10/2019 Ch13 Annotated 22/30

Silberschatz, Galvin and Gagne 2002 13.22Operating System Concepts

Kernel Data Structures

Kernel keeps state info  for I/O components, including open f i le

tables , network connections, character device state

used by device drivers in manipulating devices and datatransfer, and in for error recovery

data that has images on the disk must be kept in synch withdisk copy.

Many, many complex data structures to track buffers, memoryallocation, “dirty” blocks 

Some use object-oriented methods and message passing toimplement I/O

Make data structures object oriented classes to encapsulate

the low level nature of the “device” - UNIX provides aseamless interface such as this.

Page 23: Ch13 Annotated

8/10/2019 Ch13 Annotated 23/30

Silberschatz, Galvin and Gagne 2002 13.23Operating System Concepts

UNIX I/O Kernel Data Structure

Fig. 13.9 

Refer to chapter 11 and 12 on files 

Page 24: Ch13 Annotated

8/10/2019 Ch13 Annotated 24/30

Silberschatz, Galvin and Gagne 2002 13.24Operating System Concepts

Mapping I/O Requests to Hardware Operations

Consider reading a file from disk for a process:

How is connection made from file-name to disk controller: 

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

See the 10 step scenario on pp. 479-481 (Silberschatz, 6th ed.)

for a clear description.

Page 25: Ch13 Annotated

8/10/2019 Ch13 Annotated 25/30

Silberschatz, Galvin and Gagne 2002 13.25Operating System Concepts

Life Cycle of An I/O Request

Data already in bufferEx read ahead

Page 26: Ch13 Annotated

8/10/2019 Ch13 Annotated 26/30

Silberschatz, Galvin and Gagne 2002 13.26Operating System Concepts


STREAM  – a full-duplex communication channel betweena user-level process and a device

A STREAM consists of:

- STREAM head interfaces with the user process

- driver end interfaces with the device- zero or more STREAM modules between them.

Each module contains a read queue and a write queue

Message passing is used to communicate betweenqueues

Page 27: Ch13 Annotated

8/10/2019 Ch13 Annotated 27/30

Silberschatz, Galvin and Gagne 2002 13.27Operating System Concepts

The STREAMS Structure


Page 28: Ch13 Annotated

8/10/2019 Ch13 Annotated 28/30

Silberschatz, Galvin and Gagne 2002 13.28Operating System Concepts

Performancesect 13.7 

I/O a major factor in system performance:

Places demands on CPU to execute device driver, kernel I/O code

resulting in context switching

interrupt overhead 

Data copying - loads down memory bus 

Network traffic especially stressful

See bulleted list on page 485 (Silberschatz, 6th ed.)

Improving Performance See bulleted list on page 485 (Silberschatz, 6th ed.) 

Reduce number of context switches

Reduce data copying

Reduce interrupts by using large transfers, smart controllers, polling


Move proccessing primitives to hardware

Balance CPU, memory, bus, and I/O performance for highestthroughput

Page 29: Ch13 Annotated

8/10/2019 Ch13 Annotated 29/30

Silberschatz, Galvin and Gagne 2002 13.29Operating System Concepts

Intercomputer Communications- omit for now 

Page 30: Ch13 Annotated

8/10/2019 Ch13 Annotated 30/30

Device-Functionality ProgressionWhere should I/O functionality be implemented? Applicationlevel … device hardware 

Decision depends on trade-offs in the design layers: