Chapter 13: IO Systems 6th ed

1
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. Instructors annotations in blue Updated
12/5/03
2
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
  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

3
A Typical PC Bus Structure
4
Device I/O Port Locations on PCs (partial)
Various ranges for a device includes both control
and data ports
5
Polling

• Handshaking
• Determines state of device
• command-ready
• busy
• Error
• Busy-wait cycle to wait for I/O from deviceWhen
  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

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

7
Interrupt-Driven I/O Cycle
Go away do Something else gt
8
Intel Pentium Processor Event-Vector Table
Interrupts 0-31 are non-maskable - cannot be
disabled
9
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.

10
Six Step Process to Perform DMA Transfer
11
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

12
A Kernel I/O Structure
System calls gt user API
gt Example ioctl() generic call (roll your
own) in UNIX (p. 468), and other more specific
commands or calls open, read, ...
Fig. 13.6
13
Characteristics of I/O Devices
Device driver must deal with these at a low level
Use of I/O buffering
14
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 xfrs blocks at a time - as in
  paging
• DMA transfer is block oriented
• Character devices include keyboards, mice, serial
  ports
• Device driver xfrs 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

15
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!

16
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

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

18
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

19
Sun Enterprise 6000 Device-Transfer Rates
20
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?

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

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

23
UNIX I/O Kernel Data Structure
Refer to chapter 11 and 12 on files
Fig. 13.9
24
Mapping I/O Requests to Hardware Operations

• Consider reading a file from disk for a
  processHow 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.

25
Life Cycle of An I/O Request
?Data already in buffer Ex read ahead
26
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

27
The STREAMS Structure
28
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
• Use DMA
• Move proccessing primitives to hardware
• Balance CPU, memory, bus, and I/O performance for
  highest throughput

29
Intercomputer Communications- omit for now
30
Device-Functionality Progression
Where should I/O functionality be implemented?
Application level device hardware Decision
depends on trade-offs in the design layers