Presentation is loading. Please wait.

Presentation is loading. Please wait.

Operating Systems 12. I/O Systems (Ch. 12, S&G) Objectives

Similar presentations

Presentation on theme: "Operating Systems 12. I/O Systems (Ch. 12, S&G) Objectives"— Presentation transcript:

1 Operating Systems 12. I/O Systems (Ch. 12, S&G) Objectives
Certificate Program in Software Development CSE-TC and CSIM, AIT September--November, 2003 12. I/O Systems (Ch. 12, S&G) 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 device’s 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 monitor processor SCSI bus disk cache disk graphics controller bridge/memory controller memory SCSI controller PCI Bus IDE disk controller expansion bus interface keyboard Expansion Bus disk disk 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 F DMA controller timer F hard disk controller F parallel port 3D0-3DF graphics controller 3F0-3F7 floppy drive controller : :

9 2.4. Registers <--> 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 device’s status register until is it clear/false busy-waiting (polling) continued

12 3. The host sets the ready bit of the command register.
2. The host sets the write bit of the device’s 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 device’s 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
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 2.6. Interrupt Driven I/O Cycle CPU I/O Controller 1 2 device driver initiates I/O 7 initiates I/O CPU checks for interrupts between instructions 3 input ready, or output complete, or error generate interrupt signal 4 CPU receives interrupt, transfers control to interrupt handler 5 6 interrupt handler: processes data, returns CPU resumes interruped 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 Stack fault General protection Page fault Intel reserved 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 host’s 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 PCI Bus
buffer CPU/memory bus PCI Bus IDE disk controller disk disk

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 CPU’s 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 PCI bus device controller
A Kernel I/O Structure Fig. 12.6, p.409 kernel kernel I/O subsystem SCSI device driver keyboard device driver mouse device driver PCI bus device driver floppy device driver ATAPI device driver SCSI device controller keyboard device controller mouse device controller PCI bus device controller floppy device controller ATAPI device controller SCSI devices keyboard mouse PCI bus floppy disk drives disk & tape drives

28 Advantages Simplifies OS developer’s 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 Example disk-transfer mode character terminal block disk access method sequential modem random CD-ROM transfer schedule synchronous tape asynchronous keyboard sharing dedicated tape sharable keyboard : continued

30 Aspect. Variation. Example device speed. latency. seek time
Aspect Variation Example device speed latency seek time transfer rate delay between ops I/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 Java’s 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 hard disk

45 Slow producer buffer Fast consumer buffer hard disk

46 Slow producer buffer Fast consumer buffer hard disk

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 4.5. UNIX I/O Kernel Data Structures kernel system open-file table active inode table file-system record inode pointer pointers to functions: read(), write(), select(),... file descriptor network record socket d.s. pointer pointers to functions: read(), write(), select(),... process open-file table network info table user process

51 Details are hidden from the user by standard abstractions:
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 , p.422 user process Request I/O I/O completed yes return from call system call Transfer data to process can satisfy already? kernel I/O subsystem no Send request to device driver. Block process. kernel I/O subsystem time continued

54 Determine when I/O completed. Tell I/O subsystem. Carry out request.
Send commands to controller. Block. device driver Receive interrupt. Store data in dd buffer. Signal dd. device controller commands interrupt handler keyboard device controller 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:
<major, minor> 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 controller’s 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. Sending System Fig. 12.11, p.425 hard ware 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 context switch context switch Sending System user process kernel

61 network packet received
hard ware Receiving System network network adapter interrupt generated state saved device driver network subdaemon kernel context switch context switch context switch kernel network daemon

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 , p.426 I/O functionality implemented using: application code kernel code device driver code increased flexibility increased development time increased efficiency increased development cost increased hiding from user device controller code (hardware) device code (hardware)

Download ppt "Operating Systems 12. I/O Systems (Ch. 12, S&G) Objectives"

Similar presentations

Ads by Google