Title: InputOutput Systems
1Input-OutputSystems
2Chapter 13 I/O Systems
- 13.1 I/O Hardware
- 13.2 Application I/O Interface
- 13.3 Kernel I/O Subsystem
- 13.4 I/O Requests to Hardware Operations
- 13.5 UNIX STREAMS
- 13.6 Performance
3OS Components
Processes
Memory Manager
Storage Manager
File Manager
I/O Manager
Networking
System Protection
Command Interpreter
4I/O Hardware
- Incredible variety of I/O devices
- Common concepts
- Port (e.g. serial port)
- Bus (daisy chain or shared direct access)
- Controller (host adapter)
- I/O instructions control devices
- Devices have addresses, used by
- Direct I/O instructions
- Memory-mapped I/O
13.1
5I/O Term Definitions
- Port a connection point
- Bus
- A set of wires and a rigidly defined protocol
that specifies a set of messages that can be
carried on the wires. - Daisy chain devices bus-connected in series
- Controller a collection of electronics that
operates a port, a bus, or a device. - host adapter controller on plug-in card
13.2
6A Typical PC Bus Structure
13.2, Figure 13.1
7Latest PC
System Bus 533 MHz
P4
8I/O Styles
- Direct I/O
- Write/read directly to device registers
- Memory-mapped I/O
- Device registers are mapped to memory
- Fast
- e.g. graphics controller has a memory-mapped
region to hold screen contents - but pointer errors can be severe
13.2
9I/O Device
10Registers for PCI 6208 A/D card
- PCI Configuration Registers
- Initialized and controlled by PCI PnP BIOS
- Local Configuration Registers
- PCI bus controller from PLX Technology Inc.
- PCI-6208 Registers
- I/O Address Map
- Analog Output Status Register
Offset
6208V
0x00
V0
0x02
V1
0x04
V2
0x06
V3
D0
0x08
V4
1-bit Data_Send
0x0A
V5
D16 D1
11Typical I/O Port Registers
- Status Register
- Read by the host
- States, such as command completion, data ready
- Control Register
- Written by the host, sets mode, parity check,
etc. - Data-in Register
- Read by the host to get input
- Data-out Register
- Written by the host to send input
13.2, page 459
12Typical I/O Port Addresses on PC
13.2, Figure 13.2
13386 I/O Interfacing
- I/O Mapping
- Devices reside in 80386s 64K I/O Space
- First 256 bytes directly addressable
- IN EAX,DX input to EAX from port in DX
- OUT portnum,EBX output from EBX to specified
port - Memory Mapping
- All 4 GB of real memory can be addressed
- Devices look same as system memory
- MOV AX,memloc1 input to AX from memory location
- MOV memloc2,EBX output EBX to memory location
30386 Microprocessor Handbook
14Monitoring Device Status
- Knowing when a device completes an operation
- Polling
- Waiting for a busy bit to become clear
- Interrupts
- Hardware tests flag, signal CPU when ready
- DMA
- Controller accesses memory directly
- Raises interrupt when done
13.2
15Polling
- Busy-wait cycle to wait for I/O from device
- 1. Host repeatedly reads busy bit until bit is
clear - 2. Host sets write bit in the command register
- 3. Write a byte into the data-out register
- 4. Host sets the command-ready bit
- 5. Controller replies by setting the busy bit
- 6. Controller recognizes write command
- 7. Controller reads data-out register, sends data
- 8. Controller clears the command-ready bit
- 9. Controller clears the error bit
- 10. Controller clears the busy bit
13.2.1
16Polling
- copy_from_user(buffer, p, count)
- for (i0 i lt count i)
- while(print_status_reg ! READY)
- printer_data_register pi
-
- return_to_user()
Control Register
error bit
Device
Host
data out
13.2.1
17Interrupts
- Process Device driver initiates some I/O.
- I/O controller gets device to perform an action
- When ready, device controller raises an interrupt
by asserting a signal on the interrupt request
line. - CPU catches interrupt, dispatches to interrupt
handler - Interrupt handler clears the interrupt, services
the device, and returns to the calling task - Calling task resumes processing, and
- May request more I/O from the device driver
13.2.2
18Interrupts
Calling
Driver
Handler
Device Controller
13.2.1, from Figure 4.1 (page 97)
19Interrupt-Driven I/O Cycle
13.2.2, Figure 13.3
20Interrupts
- Interrupt vector
- to dispatch interrupt to correct handler
- Multilevel interrupts
- based on priority
- Unmaskable, e.g. unrecoverable memory errors
- Maskable to ignore or delay some interrupts
- Interrupt mechanism also used for exceptions
- e.g. Divide by zero
- e.g. Accessing protected or nonexistent memory
- e.g. Attempt to execute privileged instruction as
user
13.2.2
21Pentium Event-Vector Table
13.2.2, Figure 13.4
22Interrupts for OS Use
- Time slice interruption for context switching
- Page fault interrupt for virtual paging
- Suspend current process
- Invoke page-fault handler
- Move current process to wait queue
- Retrieve status of page cache
- Request a new page from the disk system
- Schedule another process
- System call invokes a software interrupt or trap
- Argument identifies needed kernel routine
- Save state of user code
- Switch to supervisor mode, execute requested
operation
13.2.2
23Direct Memory Access
- Used to avoid programmed I/O for large data
movement - i.e. having CPU move data a byte at a time
- Requires DMA controller
- Bus mastering boards have own DMA
- Bypasses CPU to transfer data directly between
I/O device and memory - Operates memory bus directly
- DMA request alternates with DMA acknowledge
13.2.3
24Process to Perform DMA Transfer
13.2.3, Figure 13.5
25Application I/O Interface
- Abstraction, encapsulation, layering
- Encapsulate device behaviors in generic classes
- Device-driver layer hides differences among I/O
controllers from kernel
User-level I/O software
Device-independent OS software
Device drivers
Interrupt handlers
Device Controller
Hardware
Device
13.3
26A Kernel I/O Structure
13.3, Figure 13.6
27Application I/O Interface
- Devices vary in many dimensions
- Character-stream or block
- Sequential or random-access
- Synchronous or asynchronous (unpredictable)
- Sharable or dedicated (to a process or thread)
- Speed of operation (bytes/sec to GB/sec)
- Read-write, read only, or write only
13.3
28Characteristics of I/O Devices
13.3, Figure 13.7
29Data Transfer Mode
- Block Devices
- e.g. disk drives, tape drives
- Commands include read, write, seek
- Access a linear array of blocks
- Character Devices
- e.g. mouse, keyboard
- Commands include get, put
- Network Devices
- Socket connections, messages
13.3
30Blocking and Nonblocking I/O
- Blocking system call
- Calling process suspended until I/O completed
- Normal application interface, easier to use
- Nonblocking system call
- I/O call returns right away with what is
available - Implemented with multi-threading
- e.g. mouse and keyboard user interface with
screen display - Asynchronous
- I/O call returns right away, arranges for future
completion of I/O - Invokes software interrupt, callback routine, or
just variable change
13.3.4
31Block Devices
- E.g. disk drives, tape drives
- Commands include read, write, seek
- Raw I/O accesses a linear array of blocks
- File-system, normal means of access
- Memory-mapped file access possible, using a
virtual memory array copy of the file
13.3.1
32Character Devices
- Character devices
- e.g. keyboards, mice, serial ports
- Commands include single character get, put
- Libraries layered on top offer line-at-time
access in a buffer (e.g. allow line editing) - Quick brown focltbackspacegtx
13.3.1
33Network Devices
- Varying enough from block and character to have
own interface - Unix and Windows NT/9x/2000 include socket
interface - Separates network protocol from network operation
- Includes select() functionality
- Approaches vary widely
- pipes, FIFOs, streams, queues, mailboxes
13.3.2
34Select( )
- Select() allows the process to instruct the
kernel to wait for any one of multiple events to
occur, and to wake up the process when it occurs
or when time is up
Number of descriptors to test
include ltsys/select.hgt include
ltsys/time.hgt int select(int maxfdp1, fd_set
readset, fd_set writeset, fd_set
exceptset, const struct timeval timeout)
Descriptors to test 1, 4, 5 ready for
reading? 2, 7 ready for writing? 1, 4 have
exceptions? 10.4 sec elapsed
Null to wait forever, 0 to poll, nonzero for
timed wait
Stevens, UNIX Network Programming, 2nd Edition,
Vol 1, page 150
35Clocks and Timers
- Provide current time
- Programmable interrupt timer for
- Elapsed time,
- Periodic interrupts to trigger operations
- e.g. for periodic cache write to disk
- e.g. to time out slow network operations
- e.g. to time user I/O operations
- Hardware clock at 16 60 ticks per second
somewhat inaccurate. - ioctl (on UNIX) covers odd aspects of I/O such as
clocks and timers
13.3.3
36Kernel I/O Subsystem Services
- Scheduling
- Execute requests in best order
- Buffering
- Store data in memory while transferring between
devices - Caching
- Hold a copy of data for fast access
- Spooling
- Hold output that cannot accept interleaved data
streams
13.4
37Kernel I/O Subsystem Services
- Error Handling
- Recovery from device errors, with log file
- Data Structures
- Open file tables
- Cache maintenance and checking
- Communications
- Object-oriented message-passing (Windows)
13.4
38I/O Call Scheduling
- Reasons for Scheduling
- Order from applications is rarely optimal
- Improve system performance
- Share device fairly among processes
- Reduce average waiting time
- e.g. schedule disk head seeking for efficiency
- Basis for reordering I/O requests
- Fairness, so no one application suffers
- Priority, e.g. virtual memory over user app
- Implementation
- Maintain queue for each device
13.4.1
39Buffering
- Buffering store data in memory while
transferring between devices - To cope with device speed mismatch
- e.g. double buffering between modem and disk
- To cope with device transfer size mismatch
- e.g. message disassembly and reassembly of
messages in networking - To maintain copy semantics
- e.g. if data is selected to be written to disk,
copy it to a kernel buffer before returning
control to the application, to ensure that
unchanged data will actually be written
13.4.2
40Sun Enterprise 6000 Device-Transfer Rates
13.4.2, Figure 13.8
41Caching and Spooling
- Caching fast memory holding copy of data
- Always just a copy (buffer may have original
only) - Key to performance (e.g. of a disk)
- Spooling hold output for a device
- If device can serve only one request at a time
(e.g. printer) - Managed by system daemon process or in-kernel
thread - Device reservation exclusive access to a device
- System calls for allocating and de-allocating
tape drives - Watch out for deadlock
13.4.3, 13.4.4
42Error Handling
- OS handles recovery from disk read, device
unavailable, transient write failures - e.g. disk read failure results in a read() retry
- e.g. network send error answered by resend
- Most return an error number or code when I/O
request fails e.g. UNIX returns errno with one
of 100 values - System error logs hold problem reports
- e.g. stored in SCSI devices for debugging
13.4.5
43Kernel Data Structures
- Kernel keeps state info for I/O components
- open file tables, network connections, character
device - Tracks buffers, memory allocation, dirty blocks
- e.g. to read user file, check buffer cache
before disk access - e.g. to read raw disk, ensure that request is a
multiple of the sector size and aligned with
sector boundaries - Object-oriented methods and message passing
- Capture differences within a uniform structure
- e.g. Windows NT converts I/O request into a
message, sent to kernel I/O manager, then the
device driver - Adds overhead, but simplifies design
13.4.6
44UNIX I/O Kernel Structure
13.4.6, Figure 13.9
45I/O Requests to Hardware Operations
- Consider whole procedure for reading a file from
disk - 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
13.5
46Name to Device Representation
- Windows
- X represents the partition,
- C as primary drive is built into the operating
system - C is mapped to a specific port address through a
device table - Device name space separate from file-system name
space within each device - UNIX
- Device name space is incorporated in regular
file-system name space - Mount table associates prefixes of path names
with specific device names - Device name is associated with ltmajor, minorgt
device number - Major number identifies device driver
- Minor number identifies port or memory-mapped
address of device
13.5
47Life Cycle of a Blocking I/O Request
11
1
2
10
3
4
5
9
8
6
7
13.5, Figure 13.10
48Life Cycle of an I/O Request
- Process issues blocking read to an open file
- Check parameters for correctness.
- Check for presence in cache, return value
- If not in cache, block process place on waiting
queue - Allocate buffer space, schedule I/O
- Device controller operates hardware
- When ready, DMA controller generates interrupt
- Interrupt handler stores data, signals device
driver, and returns - Device driver receives signal, checks status,
signals kernel I/O system - Kernel I/O transfers data to requesting process,
places process on ready queue - Scheduler assigns process to CPU
13.5
49Process State During I/O
7. Interrupt
11. Calling Process Scheduled
4. Calling process blocked
Calling
10. I/O Finished
Driver
Handler
Device Controller
Kernel I/O System
DMA Controller
50STREAMS
- STREAM a full-duplex communication channel
between a user-level process and a device - Provides a modular and incremental approach to
writing device drivers and network protocols. - STREAM components
- STREAM head interfaces with the user process
- driver end interfaces with the device
- STREAM modules may be between them
- Each module contains a read queue and a write
queue - Message passing is used to communicate between
queues
13.6
51The STREAMS Structure
write() putmsg()
read() getmsg()
This can block
Message passing
These are nonblocking
13.6, Figure 13.11
52Performance
- I/O a major factor in system performance
- Heavy demands on CPU to execute device driver,
kernel I/O code with fair, efficient scheduling. - Associated context switching stresses CPU and its
hardware caches - Data copying loads down memory bus
- Network traffic especially stressful
- e.g. remote login transmits data a character at
a time, across network layers, from local
keyboard interrupt to network daemon for that
session at the remote computer
13.7
53Intercomputer Communications
13.7
54Improving Performance
- Reduce number of context switches
- e.g. Solaris telnet daemon with kernel threads
- Reduce data copying between structures in memory
- Reduce interrupts by using large transfers, smart
controllers, polling (if short busy waits) - Use DMA to offload data copying from CPU
- Balance CPU, memory, bus, and I/O performance for
highest throughput - Use specialized CPU for terminal I/O
- I/O channels are used in mainframes, high-end
systems to keep data flowing while main CPU
processes data
13.7
55Improving Performance
- Where should I/O functionality be implemented
in device hardware, device driver, or application
software? - Initially, implement I/O algorithms at
application level, for flexibility and security - When stable, re-implement I/O routines in the
kernel, with thorough debugging - For highest performance, move to hardware in
device or controller (difficult to debug, lengthy
process, decreased flexibility)
13.7
56Device-Functionality Progression
13.7, Figure 13.13
57I/O Interface Summary
- Layers of the I/O system and their functions
Make I/O call format I/O spooling
Naming, blocking, buffering
Set up device registers check
Wake up driver when I/O done
Perform I/O