DEVICE IO

device types and categories

• block: storage, fixed size blocks, seekable, disk, tape, flash memory disk
• character: stream (no storage, no seek), terminals, serial port with modem, parallel port with printer, network card
• storage: disks, random and sequential access
• communication: network card, ports, terminals
• others like clock chip

device driver presents an abstraction of the hardware to other parts of the OS, and translates commands from them into device-dependent operations

device controller has command register, status register, and one or more data registers.

device connects to controller, which connects to the bus, works somewhat like MAR and MBR for RAM, device drivers in the OS kernel read and write the controller command, status, and data registers

IO software layers

• application or user process
• OS
  • file system manager, device independent part: user interface to the file system that handles system calls (software interrupts)
  • file system manager, device dependent part: device drivers that handle device details
  • hardware interrupt handlers
• hardware controllers: command, status, and data registers

in polling (busy waiting) IO, a device driver continually checks the busy or done bits in the status register, waiting for the bits to change, which uses up CPU cycles that some other process could use

busy waiting (polling) IO

• file manager part of OS issues read operation to device driver, like read(device, buffer address) or write(device, buffer address), which acts like a procedure call blocking the file manager until the read or write returns
• device driver checks done bit in controller status register
• driver waits for done bit to be true
• driver writes read command into controller command register
• driver checks status register in a while loop until operation is done
• driver reads controller data register and copies it to file manager address space
• driver does this in a loop until the whole disk block is retrieved
• write operation is similar except driver writes from file manager address space into controller data register in a loop before writing a write command into controller command register and busy waiting until done
• a lot of CPU cycles are consumed by the busy-waiting while loops, which could be used by other processes

interrupt driven IO

• eliminates busy-waiting while loop (the polling for IO operation completion)
• the device driver contains ``top half'' code that the file manager calls with read(device, buffer address) or write(device, buffer address)
• the file manager also contains a device IO status table, device handler code (``bottom half'' code), and interrupt handler code
• a read or write operation starts similarly to polling
• instead of busy-waiting for the IO operation to complete, the ``top half'' code enters information about the command issued to the device driver and blocked process into the status table and the OS now schedules some other ready process to use the CPU
• when the interrupt occurs indicating the IO operation is complete, the interrupt handler code calls the device handler code in the ``bottom half,'' which copies the contents of the controller data register into the file manager address space in a loop and marks the IO operation as done in the status table
• the ``bottom half'' code returns to the file manager, which can now put the blocked process into the ready queue and remove the entry in the status table

remember: when an interrupt occurs, the CPU finishes the current instruction, changes to kernel mode, saves the current PC contents, saves all other register values, disables interrupts, and starts executing code to determine which device controller generated the interrupt; then it executes specific device driver code; when done handling the interrupt, the PC and other registers are loaded with the saved values, interrupts are enabled, and the CPU switches back to user mode

from the viewpoint of the individual user, polling is faster and better, but from the viewpoint of overall system efficiency, interrupts are better; the overall throughput of the system is improved by the overlap of CPU processing and IO processing in an interrupt driven system, even though the turnaround time of a particular process might be longer.

Direct memory access (DMA) IO

• requires DMA enhanced controller
• controller given command: (read or write, file manager buffer memory address, byte count)
• controller copies block of count bytes from its internal buffer to memory address in file manager for a read
• controller copies block of count bytes from memory address in file manager to its internal buffer for a write
• the controller then generates interrupt, now that it has copied all requested bytes from or to the file manager buffer
• the only downside is the device controller and the CPU must share the system bus to RAM while the controller copies bytes to of from the file manager buffer in RAM and the CPU reads and writes RAM

port-based IO

• CPU has register load and store instructions to read and write RAM, and IN and OUT instructions to read and write device controller registers (command, status, data)
• IO address space (2¹⁶ locations) separate from RAM address space
• system bus has IO line
• IO bus line is off for RAM reads and writes
• IO bus line is on during IN and OUT instructions
• each device controller register has its own address in IO address space
• device controllers watch bus when IO line is on
• RAM chips watch bus when IO line is low

memory-mapped IO

• no separate IN and OUT instructions needed
• instead the controller registers are mapped into a range of RAM addresses
• the RAM chips ignore any address on the system bus in this range
• the device controllers watch the system bus when an address on it is in this range
• the OS uses register load and store CPU instructions to read and write the device controller registers
• advantage compared to port-based IO: no opcodes needed for IN and OUT
• disadvantage compared to port-based IO: total size of RAM is reduced some

original IBM PC architecture using Intel 8088 chip had RAM from 0 to 640 KB and memory-mapped IO from 640 KB to 1 MB (addresses are 20 bits in length) for buffers, I think, and IN and OUT instructions for reading and writing device controller registers

busy-waiting IO, interrupt-driven IO, DMA IO can be used with either port-based IO or memory-mapped IO (orthogonal); the choice is completely independent; think of a menu in a restaurant: choose one from column A of busy waiting or interrupt driven or DMA and then choose one from column B of port based or memory mapped

clock chips generate periodic interrupts and clock chip interrupt handler does the following

• update time of day
• CPU usage: decrement time slice counter at every clock tick, when counter reaches zero, schedule another process from the ready queue, add time slice to total CPU time used by process (accounting)

disks: randomly accessed storage devices

• rotating hard (internal, nonremovable) disks, floppy disks, Zip disks, no moving parts flash memory disks
• the file manager stores logically contiguous information (a file) in noncontiguous sectors on the disk
• platter, surface, cylinder, track, sector, disk arm, read-write heads
• seek time (5--15 ms) is the dominant component of total sector access time
• rotational delay (latency) is about one half the revolution time
• floppy disks spin 360 rpm; hard disks spin 5400, 7200, 10000 rpm.
• for hard disks, rotational delay is 3 to 8 milliseconds and transfer time is based on sectors per track

seek (disk arm) scheduling (optimization) can be done since this is dominant component

• used in multiprogramming when the OS has a queue of disk IO operations to do
• goals: minimize arm movement, minimize average response time, minimize statistical variance of response times
• time to read or write a sector on disk = seek time (5-15 ms) + rotational delay (3-8 ms) + transfer time (at a rate of some number of sectors in a track per revolution)
• time to read a random 512 byte sector from a disk with 2048 sectors per track, spinning 6000 revolutions per minute, and 10 ms seek time is 10 ms + 5 ms + 5 micros ~= 15 ms
• FCFS: fair, but no optimization (first come first served), example 76--->124--->17--->269--->201--->29--->137--->12 = 880 total FCFS tracks traversed, a lot of jumping around
• SSTF: pick closest cylinder to seek to next from the queue of outstanding requests, reduces average service time, but starvation possible, large variance in service times, shortest seek time first, example 76--->29--->17--->12--->124--->137--->201--->269 = 321 total SSTF tracks traversed, but starvation of far away requests is possible under heavy load
• SCAN (elevator, LOOK): handle all requests in one direction, then reverse and handle all requests in other direction, not as small average service time but smaller variance, sweeps back and forth over the disk, example 76--->124--->137--->201--->269--->29--->17--->12 = 450 total LOOK tracks traversed, no starvation
• seek optimization called ``native command queueing'' in serial ATA drives (PC World article, local copy of it, PDF whitepaper)

More seek (disk arm) scheduling examples.

• FCFS
  • from 15, service track requests at 4, 40, 11, 35, 7, 14
  • total tracks traversed: 135=(15-4)+(40-4)+(40-11)+(35-11)+(35-7)+(14-7)
• SSTF
  • from 15, service track requests at 4, 40, 11, 35, 7, 14
  • total tracks traversed: 47=(15-14)+(14-11)+(11-7)+(7-4)+(35-4)+(40-35)
• SCAN (elevator, LOOK)
  • from 15, service track requests at 4, 40, 11, 35, 7, 14
  • assume movement is up
  • total tracks traversed: 61=(35-15)+(40-35)+(40-14)+(14-11)+(11-7)+(7-4)

grocery store shopping analogy, oh no not again, going down a list in order (FCFS), going to the closest item next (SSTF), going up and down aisles (SCAN)

monitors

• VRAM is on video card
• map (parts of) VRAM into RAM
• CPU writes to VRAM

keyboard generates interrupt for each key pressed or released

• raw mode
• cooked mode
• driver echos keys typed to output

serial port: mouse, modem

• command, status, and data registers
• interrupt driven
• DMA output, silo input

home page: http://elvis.rowan.edu/~hartley/index.html
e-mail: hartley@elvis.rowan.edu