InputOutput Systems - PowerPoint PPT Presentation

1 / 57
About This Presentation
Title:

InputOutput Systems

Description:

A set of wires and a rigidly defined protocol that specifies ... e.g. message disassembly and reassembly of messages in networking. To maintain 'copy semantics' ... – PowerPoint PPT presentation

Number of Views:87
Avg rating:3.0/5.0
Slides: 58
Provided by: sinc150
Category:

less

Transcript and Presenter's Notes

Title: InputOutput Systems


1
Input-OutputSystems
  • Chapter 13

2
Chapter 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

3
OS Components
Processes
Memory Manager
Storage Manager
File Manager
I/O Manager
Networking
System Protection
Command Interpreter
4
I/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
5
I/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
6
A Typical PC Bus Structure
13.2, Figure 13.1
7
Latest PC
System Bus 533 MHz
P4
8
I/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
9
I/O Device
  • PCI6208 D/A Converter

10
Registers 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


11
Typical 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
12
Typical I/O Port Addresses on PC
13.2, Figure 13.2
13
386 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
14
Monitoring 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
15
Polling
  • 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
16
Polling
  • 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
17
Interrupts
  • 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
18
Interrupts
Calling
Driver
Handler
Device Controller
13.2.1, from Figure 4.1 (page 97)
19
Interrupt-Driven I/O Cycle
13.2.2, Figure 13.3
20
Interrupts
  • 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
21
Pentium Event-Vector Table
13.2.2, Figure 13.4
22
Interrupts 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
23
Direct 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
24
Process to Perform DMA Transfer
13.2.3, Figure 13.5
25
Application 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
26
A Kernel I/O Structure
13.3, Figure 13.6
27
Application 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
28
Characteristics of I/O Devices
13.3, Figure 13.7
29
Data 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
30
Blocking 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
31
Block 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
32
Character 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
33
Network 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
34
Select( )
  • 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
35
Clocks 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
36
Kernel 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
37
Kernel 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
38
I/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
39
Buffering
  • 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
40
Sun Enterprise 6000 Device-Transfer Rates
13.4.2, Figure 13.8
41
Caching 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
42
Error 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
43
Kernel 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
44
UNIX I/O Kernel Structure
13.4.6, Figure 13.9
45
I/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
46
Name 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
47
Life Cycle of a Blocking I/O Request
11
1
2
10
3
4
5
9
8
6
7
13.5, Figure 13.10
48
Life 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
49
Process 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
50
STREAMS
  • 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
51
The STREAMS Structure
write() putmsg()
read() getmsg()
This can block
Message passing
These are nonblocking
13.6, Figure 13.11
52
Performance
  • 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
53
Intercomputer Communications
13.7
54
Improving 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
55
Improving 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
56
Device-Functionality Progression
13.7, Figure 13.13
57
I/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
Write a Comment
User Comments (0)
About PowerShow.com