Device I/O I/O architectures: busses 10A I/O Architectures 10B - PDF document

Device I/O I/O architectures: busses • 10A I/O Architectures • 10B I/O Mechanisms CPU controller • 10C Disks control address main bus • 10D Low Level I/O Techniques data interrupts • 10E Higher Level I/O Techniques memory controller • 10I Polled/Non-Blocking I/O • 10J User-mode Asynchronous I/O • 10U User-mode device drivers device • 10F Plug-In Device Driver Architectures Memory type busses TERMS: Bus Arbitration & Mastery • Initially back-plane memory-to-CPU interconnects • bus master − a few “bus masters”, and many “slave devices” − any device (or CPU) that can request the bus − arbitrated multi-cycle bus transactions − one can also speak of the “current bus master” request, grant, address, respond, transfer, ack • bus slave operations: read, write, read/modify/write, interrupt − a device that can only respond to bus requests • originally most busses were of this sort • bus arbitration − ISA, EISA, PCMCIA, PCI, cPCI, video busses, ... − process of deciding to whom to grant the bus − distinguished by may be based on time, geography or priority form-factor, speed, data width, hot-plug, maximum length, ... may also clock/choreograph steps of bus cycles bridging, self identifying, dynamic resource allocation, … bus arbitrator may be part of CPU or separate Network type busses I/O architectures: devices & controllers • evolved as peripheral device interconnects • I/O devices − SCSI, USB, 1394 (firewire), Infiniband, ... − peripheral devices that interface between the computer and other media (disks, tapes, networks, − cables and connectors rather than back-planes serial ports, keyboards, displays, pointing devices, − designed for easy and dynamic extensibility etc.) − originally slower than back-plane, but no longer • device controllers connect a device to a bus • much more similar to a general purpose network − communicate control operations to device − packet switched, topology, routing, node identity − relay status information back to the bus − may be master/slave (USB) or peer-to-peer (1394) − manage DMA transfers for the device − may be implemented by controller or by host − generate interrupts for the device • controller usually specific to a device and a bus 1

Device Controller Registers A simple device: 16550 UART • device controllers export registers to the bus offset contents Register − registers in controller can be addressed from bus 0 x x x x x x x x Data Register 1 MDM STS XMT RCV Interrupt Enable Register − writing into registers controls device or sends data 2 MDM STS XMT RCV Interrupt Register 3 speed BRK PARITY STOP WORDLEN Line Control Register − reading from registers obtains data/status 4 DTR RTS Modem Control Register 5 RCV EMT XMT BRK FER PER OVR RER Line Status Register 6 DCD RI DSR CTS Modem Status Register • register access method varies with CPU type A 16550 presents seven 8-bit registers to the bus. − may require special instructions (e.g. x86 IN/OUT) privileged instructions restricted to supervisor mode All communication between the bus and the device (send − may be mapped onto bus like memory data, receive data, status and control) is performed by reading from, and writing to these registers. accessed with normal (load/store) instructions I/O address space not accessible to most processes Scenario: direct I/O with polling (16550 UART registers) • 0: data – read received byte, write to transmit a byte uart_write_char( char c ) { − (or LSB of speed divisor when speed set is enabled) while( (inb(UART_LSR) & TR_DONE) == 0); • 1: interrupt enables – for transmit done, data received, cd/ring − (or MSB of speed divisor when speed set is enabled) outb( UART_DATA, c ); • 2: interrupt registers – currently pending interrupt conditions } • 3: line control register – character length, parity and speed char uart_read_char() { • 4: modem control register – control signals sent by computer while( (inb(UART_LSR) & RX_READY) == 0); • 5: line status register – xmt/rcv completion and error conditions return( inb(UART_DATA) ); • 6: modem status registers – received modem control signals } (mechanisms: direct polled I/O) performance of direct I/O • all transfers happen under direct control of CPU • CPU intensive data transfers − CPU transfers data to/from device controller registers − each byte/word requires mutiple instructions − transfers are typically one byte or word at a time • CPU wasted while awaiting completion − may be accomplished with normal or I/O instructions − busy-wait polling ties up CPU until I/O is completed • CPU polls device until it is ready for data transfer • devices are idle while we are running other tasks − received data is available to be read − I/O can only happen when an I/O task is running − previously initiated write operations are completed • how can these problems be dealt with • advantages − let controller transfer data without attention from CPU − very easy to implement (both hardware and software) − let application block pending I/O completion − let controller interrupt CPU when I/O is finally done 2

importance of good device utilization Poor I/O device Utilization • key system devices limit system performance IDLE I/O − file system I/O, swapping, network communication device BUSY • if device sits idle, its throughput drops process − this may result in lower system throughput 1. process waits to run − longer service queues, slower response times 2. process does computation in preparation for I/O operation • delays can disrupt real-time data flows 3. process issues read system call, blocks awaiting completion 4. device performs requested operation − resulting in unacceptable performance 5. completion interrupt awakens blocked process − possible loss of irreplaceable data 6. process runs again, finishes read system call • it is very important to keep key devices busy 7. process does more computation 8. Process issues read system call, blocks awaiting completion − start request n+1 immediately when n finishes Direct Memory Access I/O Interrupts • bus facilitates data flow in all directions between • device controllers, busses, and interrupts − busses have ability to send interrupts to the CPU − CPU, memory, and device controllers − devices signal controller when they are done/ready • CPU can be the bus-master − when device finishes, controller puts interrupt on − initiating data transfers w/memory, device controllers bus • device controllers can also master the bus • CPUs and interrupts − CPU instructs controller what transfer is desired − interrupts look very much like traps what data to move to/from what part of memory traps come from CPU, interrupts are caused externally − unlike traps, interrupts can be enabled/disabled − controller does transfer w/o CPU assistance − controller generates interrupt at end of transfer a device can be told it can or cannot generate interrupts special instructions can enable/disable interrupts to CPU interrupt may be held pending until s/w is ready for it Interrupt Handling Keeping Key Devices Busy Application Program • allow multiple requests pending at a time instr ; instr ; instr ; instr ; instr ; instr ; − queue them, just like processes in the ready queue user mode supervisor mode − requesters block to await eventual completions PS/PC PS/PC device • use DMA to perform the actual data transfers PS/PC requests PS/PC interrupt − data transferred, with no delay, at device speed 1 st level interrupt vector table − minimal overhead imposed on CPU return to interrupt handler user mode • when the currently active request completes driver − device controller generates a completion interrupt driver 2 nd level handler driver (device driver − interrupt handler posts completion to requester driver interrupt routine) − interrupt handler selects and initiates next transfer list of device interrupt handlers 3