Operating%20Systems

1
Operating Systems
Certificate Program in Software
DevelopmentCSE-TC and CSIM, AITSeptember--Novemb
er, 2003
12. I/O Systems(Ch. 12, SG)

• Objectives
• discuss how an OS manages and controls I/O
  operations and I/O devices

2
Contents

• 1. Issues
• 2. I/O Hardware
• 3. Application I/O Interfaces
• 4. Kernel I/O Subsystems
• 5. From I/O Requests to Hardware
• 6. Performance

3
1. Issues

• I/O is the main job in most computers
• processing is secondary
• An OS must deal with a wide variety of I/O
  devices with different properties
• mouse, hard disk, CD-ROM,joystick, keyboard, etc.

continued
4
Principal Design Aims

• Increase the standardization of the I/O software
  and hardware interfaces.
• Support many types of devices.
• Performance.
• One solution
• device driver modules with standard interfaces

5
2. I/O Hardware

• Some terminology
• port a devices connection point to the main
  processor (computer)
• bus a connection line allowing several devices
  to access the processor
• controller a chip or circuit board in the device
  that manages interaction between the device and
  processor

6
2.1. Typical PC Bus Structure
Fig. 12.1, p.399
disk
disk
SCSI bus
monitor
processor
disk
disk
cache
graphics controller
bridge/memory controller
memory
SCSI controller
PCI Bus
IDE disk controller
expansion bus interface
keyboard
Expansion Bus
disk
disk
parallel port
serial port
7
2.2. Controller Features

• Runs microcode for specific tasks
• e.g. a hard disk controller may do bad-sector
  avoidance, buffering
• Use registers for holding data, control signals
• the processor communicates with the controller by
  reading/writing to these registers
• Registers may be visible to a processor as I/O
  port addresses.

8
2.3. Some PC I/O Port Addresses
Fig. 12.2, p.400

• I/O Address Range (Hex) Device 000-00F DMA
  controller 040-043 timer 320-32F hard disk
  controller 378-37F parallel port 3D0-3DF graphic
  s controller 3F0-3F7 floppy drive controller
  

9
2.4. Registers lt--gt I/O Port

• Typically, an I/O port address is made up of 4
  registers.
• One register is usually 1- 4 bytes
• Different bits/bytes of a register are used for
  manipulating different parts of the device.

10
Register Names

• status read by a processor (host) to see if a
  device is ready to execute a command, or has
  finished a command, etc.
• control/command written by a processor (host) to
  tell the device to start/change its settings,
  etc.
• data-in read by a procesor (host)
• data-out written by a processor (host)

11
2.5. Handshaking

• Handshaking is one possible protocol between a
  host (processor) and a controller.
• Example the host writes a byte to the device
• 1. The host repeatedly reads the busy bit of the
  devices status register until is it clear/false
• busy-waiting (polling)

continued
12

• 2. The host sets the write bit of the devices
  command register and writes a byte into the
  data-out register.
• 3. The host sets the ready bit of the command
  register.
• 4. When the devices controller notices the
  ready bit, it sets the busy bit of its status
  register.

continued
13

• 5. The controller sees the write bit of its
  command register. It then reads the byte from the
  data-out register, and does the I/O.
• 6. The controller clears the command ready bit,
  and clears the status busy bit.

14
Polling a Device

• Polling often requires only 3 CPU instructions
• read the status register
• use a logical-and operation to extract the busy
  bit
• branch (goto) is not zero

continued
15

• Polling becomes inefficient if done too often.
• An alternative is to have the device interrupt
  the host (CPU) when it is free.

16
2.6. Interrupt Driven I/O Cycle
Fig. 12.3, p.403
I/O Controller
CPU
1
2
device driverinitiates I/O
7
initiates I/O
CPU checks for interruptsbetween instructions
3
input ready, or outputcomplete, or
errorgenerate interrupt signal
4
CPU receives interrupt,transfers control
tointerrupt handler
5
6
interrupt handler processes data, returns
CPU resumesinterruped task
17
More Sophistication

• Defer interrupt handling during critical
  processing.
• Use more efficient ways of finding the right
  interrupt handler.
• Multi-level interrupts.
• Multiple interrupt request lines
• nonmaskable and maskable lines

18
Interrupt Vector Table

• An interrupt vector table is used to map an
  interrupt to a routine
• done by treating the interrupt number as an
  offset in the table
• called an interrupt vector
• Each entry in the table may be a list (chain) of
  handlers
• allows overloading of the interrupt number

19
Part of a Pentium Vector Table
Fig. 12.4, p.404

• Vector Number Description 0 Divide
  error 3 Breakpoint 5 Bound range
  error 7 Device not available 12 Stack
  fault 13 General protection 14 Page
  fault 19-31 Intel reserved 32-255 Maskable
  interrupts

20
Threads and Interrupts

• A threaded kernel is useful for implementing
  multiple interrupt priorities.
• The Solaris thread scheduler allows low priority
  interrupt handlers (threads) to be pre-empted by
  high priority interrupt handlers (threads).

21
2.7. Direct Memory Access (DMA)

• When the hosts CPU does device handshaking, it
  is called Programmed I/O (PIO)
• a waste of CPU resources
• Instead, offload the work to a DMA controller
• the CPU sends the I/O command to the DMA, then
  goes on with other work

continued
22
Advantages

• Higher CPU performance since
• less kernel communication
• less context switching

23
DMA Diagram
Fig. 12.5, p.407
CPU
cache
DMA controller
memory
buffer
CPU/memory bus
PCI Bus
IDE disk controller
24
Cycle Stealing

• Cycle stealing occurs when the DMA controller
  uses the CPU memory bus
• the CPU is prevented from accessing memory
• this can slow down the CPUs computation

25
Direct Virtual Memory Access (DVMA)

• In DVMA, data is transferred between two
  memory-mapped devices (i.e. from controller to
  controller) without requiring main memory
• no cycle stealing required

26
3. Application I/O Interfaces

• OSes treat I/O devices in a standard way using
• abstraction, encapulation, software layering
• The user/programmer sees a standardized set of
  I/O functions.
• Differences are hidden inside kernel modules
  called device drivers.

27
A Kernel I/O Structure
Fig. 12.6, p.409
kernel
kernel I/O subsystem
SCSIdevice driver
keyboarddevice driver
mousedevice driver
PCI busdevice driver
floppydevice driver
ATAPIdevice driver
SCSIdevice controller
keyboarddevice controller
mousedevice controller
PCI busdevicecontroller
floppydevice controller
ATAPIdevice controller
SCSIdevices
keyboard
mouse
PCI bus
floppydisk drives
disk tape drives
28
Advantages

• Simplifies OS developers work.
• Benefits hardware manufacturers
• But
• different OSes have different standard device
  driver interfaces.

29
3.1. Characteristics of I/O Devices
Fig. 12.7, p.410

• Aspect Variation Exampledisk-transfer mode
  character terminal block diskaccess
  method sequential modem random CD-ROMtransf
  er schedule synchronous tape asynchronous key
  boardsharing dedicated tape sharable keybo
  ard

continued
30

• Aspect Variation Exampledevice
  speed latency seek time transfer
  rate delay between opsI/O direction read-only
  CD-ROM write-only graphics
  ctrller read-write disk

31
3.2. Character and Block Devices

• Character device
• transfer byte by byte
• Block device
• treat blocks of bytes as the transfer unit
• Standard file-system interface
• read(), write(), seek(), etc
• Memory mapping
• useful for executing kernel modules/services

32
3.3. Network Devices

• Distinguished due to differences in addressing
  and performance (reliablility, data sequencing,
  speed).
• Standard interface
• sockets, message packets, streams
• select() for monitoring collections of sockets

continued
33

• Other UNIX (inter-process) communication
  features
• half-duplex pipes
• full-duplex FIFOs (queues)
• message queues

34
3.4. Clocks and Timers

• Basic uses
• get the current time/the elapsed time
• set a timer to trigger an operation at time
  T(e.g. time-slice a process)
• Timers have coarse resolution (20-60 ticks/sec),
  which limits the precision of triggers
• a CPU can execute 100M instructions/sec

35
3.5. Blocking Nonblocking I/O

• Blocking (synchronous) I/O
• the application is suspended until the I/O is
  completed
• easy to understand/implement
• Nonblocking (asynchronous) I/O
• the application does not wait

continued
36

• Some software requires nonblocking I/O
• most games software has to be able to receive
  user input from the keyboard at any time while
  updating the screen continuously

37
Implementing Nonblocking I/O

• Threads
• place the blocking I/O in one thread, and let the
  other behaviour execute in other threads
• Use nonblocking I/O system calls
• they return immediately with whatever was
  available
• e.g. select() called with a time-out of 0

continued
38

• Use asynchronous I/O system calls
• they return immediately, but the completed I/O
  result is available some time later
• the result can be made available in different
  ways
• a special variable
• raising a signal (software interrupt)
• calling a callback function(e.g. used in Javas
  event model)

39
4. Kernel I/O Subsystems

• These are features built on top of the hardware
  and device-driver infrastructure, including
• I/O scheduling
• buffering
• caching
• spooling

40
4.1. I/O Scheduling

• Scheduling (re-ordering) is carried out to
• improve overall system performance
• share device access fairly
• reduce average waiting time

41
Scheduling Example

• Three jobs want to read from a hard disk. The
  read arm is currently near the beginning of the
  disk.
• job 1 requests a block at the end of the disk
• job 2 requests a block near the start
• job 3 requests a block in the middle
• New schedule jobs 2, 3, 1

42
4.2. Buffering

• A buffer is a memory area that stores data while
  it is being transferred between two devices, or
  between a device and a process.

43
Three Uses for Buffering

• Cope with speed mismatches
• e.g. between a modem and hard disk
• double buffering may be used
• Cope with different data-transfer sizes
• e.g. packet transfer over a network
• Support copy semantics for application I/O
• e.g. so write() data cannot be changed

44
Double Buffering Illustrated
VUW cs305
Slow producer
buffer
Fast consumer
buffer
harddisk
45
Slow producer
buffer
Fast consumer
buffer
harddisk
46
Slow producer
buffer
Fast consumer
buffer
harddisk
47
4.3. Caching

• A cache is a region of fast memory that holds
  copies of data
• used to speed-up reuse and updates
• e.g. recently read instructions copied from the
  hard disk
• Cache and buffer difference
• a buffer may hold the only copy of a data item

48
4.4. Spooling

• A spool is a buffer (or buffers) used to hold
  output for a device while the device is
  processing the current job.
• The device can only process one job at once
• e.g. a printer, tape reader
• Spool management is often done by a dedicated
  system daemon (process)

49
Spooling Diagram
VUW, cs305
spool daemon
Program
Program
Program
Printer driver
Printer driver
50
4.5. UNIX I/O Kernel Data Structures
Fig. 12.9, p.419
kernel
system open-file table
activeinode table
file-system recordinode pointerpointers to
functionsread(), write(), select(),...
filedescriptor
network recordsocket d.s. pointerpointers to
functionsread(), write(), select(),...
process open-filetable
network infotable
user process
51

• A variety of I/O components are
  controlled/monitored through the open file
  table.
• Details are hidden from the user by standard
  abstractions
• e.g. read() works with files and network sockets

52
5. From I/O Requests to Hardware

• How does the OS convert an I/O request into
  hardware commands?
• Consider how UNIX reads from a file on disk.

53
Lifecycle of an I/O Request
Fig. 12.10, p.422
userprocess
Request I/O
I/O completed
yes
return from call
system call
Transfer datato process
can satisfyalready?
kernelI/O subsystem
no
kernelI/O subsystem
Send request todevice driver.Block process.
time
continued
54
Determine whenI/O completed.Tell I/O subsystem.
Carry out request. Send commands tocontroller.
Block.
devicedriver
Receive interrupt.Store data in dd buffer.
Signal dd.
device controller commands
interrupthandler
keyboarddevicecontroller
Monitor device. Interrupt when I/O completed
I/O completed.Generate interrupt.
time
55
Filename to Disk Controller

• A UNIX path name has no clear separation of the
  device portion
• /home/fidji/ad/public_html/index.html
• UNIX stores a mount table (in /etc/mnttab) of
  device name to pathname details
• /dev/dsk/c1t1d0s0 /home/fidji
  /dev/dsk/c1t2d0s0 /home/hawai
  /dev/dsk/c1t4d0s0 /home/corse

continued
56

• The name (e.g. /dev/dsk/c1t1d0s0) is looked up in
  the file-system, and UNIX finds
• ltmajor, minorgt device numbers
• The major device number identifies the device
  driver type (e.g. character/block transfer).

continued
57

• The minor device number can be used to index into
  a device table to find the device controllers
  I/O port address or its memory mapped address.

58
Stream Modules

• UNIX System V allows pipelines of driver code to
  be assembled dynamically for an application.

stream head
module 1
Application
module 2
module N
driver end
hardware
59
6. Performance

• I/O is a major factor in system performance
• it uses the CPU heavily to execute device
  drivers, schedule processes
• cycle stealing
• costs of interrupt processing
• network traffic

60
Network Comms.
Fig. 12.11, p.425
hardware
char typed
system call completes
context switch
interrupt generated
interrupt handled
state saved
state saved
interrupt handled
interrupt generated
device driver
network
network adapter
kernel
device driver
contextswitch
contextswitch
SendingSystem
user process
kernel
61
networkpacket received
hardware
ReceivingSystem
network
network adapter
interrupt generated
state saved
device driver
networksubdaemon
kernel
context switch
contextswitch
contextswitch
kernel
networkdaemon
62
Ways to Improve I/O Efficiency

• Reduce the number of context switches.
• Reduce the number of data copys to/from memory.
• Reduce the number of interrupts.

continued
63

• Offload I/O work to other processors.
• Move more processing into hardware.
• Balance the performance of CPU, memory, bus, and
  the I/O.

64
Efficiency Examples

• The telnet daemon in Solaris runs inside a kernel
  thread
• that eliminates context switching between the
  daemon and the kernel
• Front-end processors
• e.g. terminal concentrators

continued
65

• DMA controllers
• I/O channels
• an I/O channel is a dedicated CPU for offloading
  I/O work from the main CPU

66
Where to put I/O Functionality?
Fig. 12.12, p.426
I/O functionalityimplemented using
application code
kernel code
device driver code
increased flexibility
increased development cost
increased hiding from user
increased development time
increased efficiency
device controller code(hardware)
device code(hardware)