1 / 66

Operating Systems

Operating Systems. Certificate Program in Software Development CSE-TC and CSIM, AIT September--November, 2003. Objectives discuss how an OS manages and controls I/O operations and I/O devices. 12. I/O Systems (Ch. 12, S&G). Contents. 1. Issues 2. I/O Hardware 3. Application I/O Interfaces

hue
Download Presentation

Operating Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Operating Systems Certificate Program in Software DevelopmentCSE-TC and CSIM, AITSeptember--November, 2003 • Objectives • discuss how an OS manages and controls I/O operations and I/O devices 12. I/O Systems(Ch. 12, S&G)

  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. disk disk 2.1. Typical PC Bus Structure Fig. 12.1, p.399 disk disk SCSI bus monitor processor disk cache disk graphics controller bridge/memory controller memory SCSI controller PCI Bus IDE disk controller expansion bus interface keyboard Expansion Bus 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 000-00F DMA controller 040-043 timer 320-32F hard disk controller 378-37F 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. 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. 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. Fig. 12.3, p.403 2.6. Interrupt Driven I/O Cycle I/O Controller CPU 1 2 device driverinitiates I/O 7 initiates I/O CPU checks for interruptsbetween instructions 3 input ready, or outputcomplete, or errorgenerate interrupt signal 4 CPU receives interrupt,transfers control tointerrupt handler 5 6 interrupt handler: processes data, returns CPU resumesinterruped 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 Description0 Divide error 3 Breakpoint 5 Bound range error 7 Device not available 12 Stack fault 13 General protection 14 Page fault 19-31 Intel reserved 32-255 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. disk disk disk disk DMA Diagram Fig. 12.5, p.407 CPU cache DMA controller memory buffer CPU/memory bus PCI Bus IDE disk controller

  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. A Kernel I/O Structure Fig. 12.6, p.409 kernel kernel I/O subsystem SCSIdevice driver keyboarddevice driver mousedevice driver PCI busdevice driver floppydevice driver ATAPIdevice driver SCSIdevice controller keyboarddevice controller mousedevice controller PCI busdevicecontroller floppydevice controller ATAPIdevice controller SCSIdevices keyboard mouse PCI bus floppydisk 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 Exampledisk-transfer mode character terminal block diskaccess method sequential modem random CD-ROMtransfer schedule synchronous tape asynchronous keyboardsharing dedicated tape sharable keyboard : continued

  30. Aspect Variation Exampledevice speed latency seek time transfer rate delay between opsI/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 harddisk

  45. Slow producer buffer Fast consumer buffer harddisk

  46. Slow producer buffer Fast consumer buffer harddisk

  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. Fig. 12.9, p.419 4.5. UNIX I/O Kernel Data Structures kernel system open-file table activeinode table file-system recordinode pointerpointers to functions:read(), write(), select(),... filedescriptor network recordsocket d.s. pointerpointers to functions:read(), write(), select(),... process open-filetable network infotable user process

More Related