Download Chapter 13 PPT Silberschatz slides (Our Text Book) on I/O systems

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
 Streams
 Performance
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
Operating System Concepts
13.1
Silberschatz, Galvin and Gagne 2002
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 and
specialized local (ex: PCI for main and SCSI for disks)
 Controller (host adapter) - HW interface between Device
and Bus - an adapter card or mother board module
Controller 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
Operating System Concepts
13.2
Silberschatz, Galvin and Gagne 2002
A Typical PC Bus Structure
Operating System Concepts
13.3
Silberschatz, Galvin and Gagne 2002
Device I/O Port Locations on PCs (partial)
Various ranges for a device includes both control and data ports
Operating System Concepts
13.4
Silberschatz, Galvin and Gagne 2002
Polling
 Handshaking
 Determines state of device
 command-ready
 busy
 Error
 Busy-wait cycle to wait for I/O from device
When not busy - set data in data port, set command
in 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
Operating System Concepts
13.5
Silberschatz, Galvin and Gagne 2002
Interrupts
 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 til
responsible for transferring data to memory when it
becomes 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.
Operating System Concepts
13.6
Silberschatz, Galvin and Gagne 2002
Interrupt-Driven I/O Cycle
Go away & do
Something else ==>
Operating System Concepts
13.7
Silberschatz, Galvin and Gagne 2002
Intel Pentium Processor Event-Vector Table
Interrupts 0-31 are non-maskable - cannot be disabled
Operating System Concepts
13.8
Silberschatz, Galvin and Gagne 2002
Direct Memory Access
 With pure interrupt scheme, CPU was still
responsible 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 up
DMA and user the data when the DMA-complete
interrupt 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/O
device and memory
 Cycle stealing: interference with CPU memory
instructions during DMA transfer. - DMA takes priority
- CPU pauses on memory part of word.
Operating System Concepts
13.9
Silberschatz, Galvin and Gagne 2002
Six Step Process to Perform DMA Transfer
Operating System Concepts
13.10
Silberschatz, Galvin and Gagne 2002
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 many
I/o devices into a few general classes.
I/O “system calls” encapsulate device behaviors in
generic 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) vs
asynchronous (unpredictable response times)
 Sharable or dedicated - implications on deadlock
 Speed of operation - device/software issue
 read-write, read only, or write only - permissions
Operating System Concepts
13.11
Silberschatz, Galvin and Gagne 2002
A Kernel I/O Structure
System calls ==>
… “user” API
==>
Example: ioctl(…)
generic call
(roll your own)
in UNIX (p. 468),
and other more
specific
commands or calls
open, read, ...
Fig. 13.6
Operating System Concepts
13.12
Silberschatz, Galvin and Gagne 2002
Characteristics of I/O Devices
Device driver must deal with these at a low level
Use of I/O buffering
Operating System Concepts
13.13
Silberschatz, Galvin and Gagne 2002
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 - interpretation
is in application (personality of file lost)
 Memory-mapped (to VM) file access possible - use memory instructions
rather 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 device
driver catagories
Operating System Concepts
13.14
Silberschatz, Galvin and Gagne 2002
Network Devices
 Varying enough from block and character to have own
interface - OS makes network device interface distinct
from disk interface - due to significant differences
between the two
 Unix and Windows NT/9i/2000 include socket interface
 Separates network protocol from network operation
 Encapsulates details of various network devices for
application … analogous to a file and the disk???
 Includes select functionality - used to manage and access
sockets - returns info on packets waiting or ability to accept
packets - avoids polling
 Approaches vary widely (pipes, FIFOs, streams, queues,
mailboxes) … you saw some of these!
Operating System Concepts
13.15
Silberschatz, Galvin and Gagne 2002
Clocks and Timers
 Provide current time, elapsed time, timer
 If programmable, interval time used for timings, periodic
interrupts
 ioctl (on UNIX) covers odd aspects of I/O such as
clocks and timers - a back door for device driver
writers (roll your own). Can implement “secret” calls
which may not be documented in a users or
programming manual
Operating System Concepts
13.16
Silberschatz, Galvin and Gagne 2002
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/O
executes
 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.
Operating System Concepts
13.17
Silberschatz, Galvin and Gagne 2002
Kernel I/O Subsystem
 See A Kernel I/O Structure slide - Fig 13.6
 Scheduling
 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 data
written 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 before
returning control to user.
 Double or “ping-pong” buffers - write in one and read from
another - decouples devices and applications
… idea can be extended to multiple buffers accesses in a circular
fashion
Operating System Concepts
13.18
Silberschatz, Galvin and Gagne 2002
Sun Enterprise 6000 Device-Transfer Rates
Operating System Concepts
13.19
Silberschatz, Galvin and Gagne 2002
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 associated
with the application AND the particular request. Could be
saved 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?
Operating System Concepts
13.20
Silberschatz, Galvin and Gagne 2002
Error Handling
 OS can 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
 CRC checks - especially over network transfers of a
lot of data, for example video in real time.
Operating System Concepts
13.21
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
 used by device drivers in manipulating devices and data
transfer, and in for error recovery
 data that has images on the disk must be kept in synch with
disk copy.
 Many, many complex data structures to track buffers, memory
allocation, “dirty” blocks
 Some use object-oriented methods and message passing to
implement I/O
 Make data structures object oriented classes to encapsulate
the low level nature of the “device” - UNIX provides a
seamless interface such as this.
Operating System Concepts
13.22
Silberschatz, Galvin and Gagne 2002
UNIX I/O Kernel Data Structure
Refer to chapter 11 and 12 on files
Fig. 13.9
Operating System Concepts
13.23
Silberschatz, Galvin and Gagne 2002
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.
Operating System Concepts
13.24
Silberschatz, Galvin and Gagne 2002
Life Cycle of An I/O Request
Data already in buffer
Ex read ahead
Operating System Concepts
13.25
Silberschatz, Galvin and Gagne 2002
STREAMS (?)
 STREAM – a full-duplex communication channel between
a 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 between
queues
Operating System Concepts
13.26
Silberschatz, Galvin and Gagne 2002
The STREAMS Structure
Operating System Concepts
13.27
Silberschatz, Galvin and Gagne 2002
Performance
sect 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
 Use DMA
 Move proccessing primitives to hardware
 Balance CPU, memory, bus, and I/O performance for highest
throughput
Operating System Concepts
13.28
Silberschatz, Galvin and Gagne 2002
Intercomputer Communications- omit for now
Operating System Concepts
13.29
Silberschatz, Galvin and Gagne 2002
Device-Functionality Progression
Where should I/O functionality be implemented? Application
level … device hardware
Decision depends on trade-offs in the design layers:
Operating System Concepts
13.30
Silberschatz, Galvin and Gagne 2002