INPUT/OUTPUT Operating system controls all I/O devices

Slides:



Advertisements
Similar presentations
Chapter 7: Deadlocks.
Advertisements

I/O Management and Disk Scheduling
Chapter 5 Input/Output 5.1 Principles of I/O hardware
Principles of I/O Hardware I/O Devices Block devices, Character devices, Others Speed Device Controllers Separation of electronic from mechanical components.
Avishai Wool lecture Introduction to Systems Programming Lecture 8 Input-Output.
Part 5 (Stallings) Input/Output 5.1 Principles of I/O hardware
1 Input/Output Chapter Principles of I/O hardware 5.2 Principles of I/O software 5.3 I/O software layers 5.4 Disks 5.5 Clocks 5.6 Character-oriented.
EEE 435 Principles of Operating Systems Principles and Structure of I/O Software (Modern Operating Systems 5.2 & 5.3) 5/22/20151Dr Alain Beaulieu.
Chapter 3 Deadlocks TOPICS Resource Deadlocks The ostrich algorithm
1 Deadlocks Chapter Resource 3.2. Introduction to deadlocks 3.3. The ostrich algorithm 3.4. Deadlock detection and recovery 3.5. Deadlock avoidance.
Silberschatz, Galvin and Gagne  Operating System Concepts Chapter 13: I/O Systems I/O Hardware Application I/O Interface Kernel I/O Subsystem.
Operating Systems Input/Output Devices (Ch , 12.7; , 13.7)
I/O Hardware n Incredible variety of I/O devices n Common concepts: – Port – connection point to the computer – Bus (daisy chain or shared direct access)
I/O Systems CS 3100 I/O Hardware1. I/O Hardware Incredible variety of I/O devices Common concepts ◦Port ◦Bus (daisy chain or shared direct access) ◦Controller.
CS 342 – Operating Systems Spring 2003 © Ibrahim Korpeoglu Bilkent University1 Input/Output – 5 Disks CS 342 – Operating Systems Ibrahim Korpeoglu Bilkent.
Device Management.
Chapter 13: I/O Systems I/O Hardware Application I/O Interface
CS 342 – Operating Systems Spring 2003 © Ibrahim Korpeoglu Bilkent University1 Input/Output – 3 I/O Software CS 342 – Operating Systems Ibrahim Korpeoglu.
1 Input/Output Chapter 3 TOPICS Principles of I/O hardware Principles of I/O software I/O software layers Disks Clocks Reference: Operating Systems Design.
1 Today I/O Systems Storage. 2 I/O Devices Many different kinds of I/O devices Software that controls them: device drivers.
Operating Systems Input/Output Devices (Ch 5: )
Operating Systems COMP 4850/CISG 5550 Disks, Part II Dr. James Money.
Chapter 13: I/O Systems I/O Hardware Application I/O Interface
Copyright ©: Nahrstedt, Angrave, Abdelzaher
I/O Tanenbaum, ch. 5 p. 329 – 427 Silberschatz, ch. 13 p
1 Input/Output. 2 Principles of I/O Hardware Some typical device, network, and data base rates.
Tanenbaum & Woodhull, Operating Systems: Design and Implementation, (c) 2006 Prentice-Hall, Inc. All rights reserved OPERATING SYSTEMS DESIGN.
Silberschatz, Galvin and Gagne  Operating System Concepts Chapter 13+14: I/O Systems and Mass- Storage Structure I/O Hardware Application I/O.
1 I/O Management and Disk Scheduling Chapter Categories of I/O Devices Human readable Used to communicate with the user Printers Video display terminals.
ITEC 502 컴퓨터 시스템 및 실습 Chapter 8-1: I/O Management Mi-Jung Choi DPNM Lab. Dept. of CSE, POSTECH.
Segmentation & O/S Input/Output Chapter 4 & 5 Tuesday, April 3, 2007.
Sistem Operasi IKH311 Masukan Luaran (Input/Output)
CSC 322 Operating Systems Concepts Lecture - 25: by Ahmed Mumtaz Mustehsan Special Thanks To: Tanenbaum, Modern Operating Systems 3 e, (c) 2008 Prentice-Hall,
I/O Systems I/O Hardware Application I/O Interface
1 Module 12: I/O Systems n I/O hardware n Application I/O Interface n Kernel I/O Subsystem n Transforming I/O Requests to Hardware Operations n Performance.
Windows Operating System Internals - by David A. Solomon and Mark E. Russinovich with Andreas Polze Unit OS6: Device Management 6.1. Principles of I/O.
© Janice Regan, CMPT 300, May CMPT 300 Introduction to Operating Systems Principles of I/0 hardware.
Deadlock Chapter 3 Thursday, February 22, Today’s Schedule Assignment #4 from Chapter 3 posted Deadlock - Chapter 3  Skip multiple resources (3.4.2.
CS 342 – Operating Systems Spring 2003 © Ibrahim Korpeoglu Bilkent University1 Input/Output CS 342 – Operating Systems Ibrahim Korpeoglu Bilkent University.
Disks Chapter 5 Thursday, April 5, Today’s Schedule Input/Output – Disks (Chapter 5.4)  Magnetic vs. Optical Disks  RAID levels and functions.
1 Deadlocks Chapter Resource 3.2. Introduction to deadlocks 3.3. The ostrich algorithm 3.4. Deadlock detection and recovery 3.5. Deadlock avoidance.
1 Deadlocks 2 Resources Examples of computer resources –printers –tape drives –tables Processes need access to resources in reasonable order Suppose.
1 Deadlocks Chapter Resource 3.2. Introduction to deadlocks 3.3. The ostrich algorithm 3.4. Deadlock detection and recovery 3.5. Deadlock avoidance.
1 Deadlocks Chapter 3. 2 Resources Examples of computer resources –printers –tape drives –tables Processes need access to resources in reasonable order.
Operating Systems 软件学院 高海昌 Operating Systems Gao Haichang, Software School, Xidian University 22 Contents  1. Introduction** 
1 Deadlocks Chapter Resource 3.2. Introduction to deadlocks 3.3. The ostrich algorithm 3.4. Deadlock detection and recovery 3.5. Deadlock avoidance.
Chapter 13: I/O Systems. 13.2/34 Chapter 13: I/O Systems I/O Hardware Application I/O Interface Kernel I/O Subsystem Transforming I/O Requests to Hardware.
Silberschatz, Galvin and Gagne  Operating System Concepts Chapter 13: I/O Systems I/O Hardware Application I/O Interface Kernel I/O Subsystem.
Chapter 5 Input/Output 5.1 Principles of I/O hardware
Device Management Mark Stanovich Operating Systems COP 4610.
Silberschatz, Galvin, and Gagne  Applied Operating System Concepts Module 12: I/O Systems I/O hardwared Application I/O Interface Kernel I/O.
I/O Software CS 537 – Introduction to Operating Systems.
MINIX Presented by: Clinton Morse, Joseph Paetz, Theresa Sullivan, and Angela Volk.
1 Device Controller I/O units typically consist of A mechanical component: the device itself An electronic component: the device controller or adapter.
1 Chapter 11 I/O Management and Disk Scheduling Patricia Roy Manatee Community College, Venice, FL ©2008, Prentice Hall Operating Systems: Internals and.
I/O Management.
Module 12: I/O Systems I/O hardware Application I/O Interface
Multiple Platters.
CS703 - Advanced Operating Systems
Operating Systems Chapter 5: Input/Output Management
Operating System Concepts
CS703 - Advanced Operating Systems
Chapter 5: I/O Systems.
Chapter 3 Deadlocks 3.1. Resource 3.2. Introduction to deadlocks
Chapter 13: I/O Systems I/O Hardware Application I/O Interface
Chapter 3 Deadlocks 3.1. Resource 3.2. Introduction to deadlocks
Introduction to Deadlocks
Chapter 3 Deadlocks 3.1. Resource 3.2. Introduction to deadlocks
Module 12: I/O Systems I/O hardwared Application I/O Interface
Presentation transcript:

INPUT/OUTPUT Operating system controls all I/O devices Two aspects of I/O devices are important for operating system: I/O hardware I/O software

Principles of I/O Hardware I/O devices Block Devices: stores information in fixed-size blocks: Disk (seek operation) Character Devices: Delivers or accept a stream of characters, without regards to any block structure: Printer, network interfaces,… Data rates of some common devices are presented in the next slide

Device controllers I/O units consist of mechanical and electronic component (electronic component called device controller or adapter) O.S initialize the controller with few parameters and controller take care of the rest. For example if a disk formatted with 256 sectors of 512 bytes a serial bit stream of 4096 bits with all necessary information is come off the drive. Controller assembles the bits and changes the bits into the bytes and send them to main memory

Device controllers

Device controllers

Memory-Mapped I/O Each controller has few register and maybe a data buffer (e.g. video RAM) to be able to communicate with CPU CPU communicates with the control registers and data buffer in three ways: 1- With assigned I/O port of that device: IN R0,4 reads the contents of port 4 MOV R0,4 reads the contents of memory word 4 and put it in R0.

Memory-Mapped I/O 2- Memory-mapped I/O: means the registers are part of the memory address (b in the previous slide) 3- Hybrid scheme: It has memory-mapped I/O data buffers and separate I/O ports for control registers In all of these cases the communication with CPU is through the buses

Memory-Mapped I/O Disadvantage of Separate I/O and memory space: In C/C++ we don’t have IN or OUT commands to read the ports Some of the advantages of Memory-mapped I/O: The device driver can be written entirely in C/C++ Every instructions that can reference memory can also reference control registers

Communication with I/O Devices If there is only one address bus all the I/O devices and memory modules can check memory references by examining this bus (see a in the next slide) But most of the systems has a dedicated high-speed memory bus for optimizing memory performance (see b in the next slide). The problem with this design for memory-mapped I/O is: I/O devices have no way of seeing memory addresses because they go by on the memory bus.

Communication with I/O Devices

Communication with I/O Devices One possible solution for the system with multiple buses is to first sending all memory references to the memory. If the memory fails to respond , then CPU tries other buses. Pentium solves this problem by filtering addresses in the PCI bridge chip. This chip checks the range of memory address references, if it finds non-memory references, it forwards them onto PCI (Peripheral Component Interconnect) bus instead of memory bus (see next slide)

Direct Memory Access (DMA) Instead of using CPU for exchanging data with different controllers DMA is often used. DMA has access to the system bus independent of CPU and it can be programmed by the CPU to exchange data (next slide shows how DMA works).

Principles of I/O Software Goals of the I/O software 1- Device independence: It should be possible to write programs that can access any I/O device without having to specify the device in advanced. For example sort<input>output should work for floppy disk , IDE or SCSI disk

Principles of I/O Software 2- Uniform naming: The name of the device should be simply an string or a integer that is not depending on the device. For example by mounting, each device can be addressed by file path name 3- Error handling: Error should be handled close to the hardware

Principles of I/O Software 4-Syncrhronous(blocking) vs. asynchronous (interrupt-driven) transfer. Most physical I/O are asynchronous but users program can be written much easier if they write with blocking I/O operations 5- Buffering, shareable and dedicated devices.

Principles of I/O Software Goals of the I/O software can be achieved by structuring the software in following layers:

Interrupt Handler The device driver blocks when it performs I/O operation. When I/O completes, the controller issues interrupt and interrupt handler runs interrupt service procedure Finally interrupt handler unblocks the driver, therefore its role is hiding the I/O controller interrupts.

Device Drivers The device drivers command the controllers by setting controller registers The device driver for each controller is created by device’s manufacturer and should be put into the kernel O.S. should have an architecture to allow the installation of different device drivers. Device drivers usually positioned below the rest of O.S. (see the next slide)

Device Drivers The most important function of device driver is changing abstract read/write request issued by device-independent software above it to concrete form. For example a disk driver converts a linear block number into head, track, sector and cylinder of the related disk. Device driver can queue the requests and report the errors to their callers.

Device-Independent I/O Software Driver contains device dependent codes. Some other functions that are common to all devices and can be used as the interface to the user-level software are in the device-independent software The basic functions of the device-independent I/O software are presented in the next slide

Device-Independent I/O Software

Uniform Interfacing for Device Drivers It means O.S. should have common functions such as naming and protection for different drivers. For example in Unix the name of /dev/disk0 can be mapped to locate any driver. It contains the i-node that contained the address of that device. Also both Unix and Windows have the protection method that can be used for all devices uniformly.

Without standard driver interface With standard driver interface

Device-Independent I/O Software Buffering can be used both in the user space and kernel space. With buffering O.S. stores the data from devices that have different speed (see next slide) Error Reporting: The general errors (not device dependent errors) is handled by O.S. For example reading or writing the wrong device

Buffering

Device-Independent I/O Software Allocating and Releasing dedicated devices is done by O.S. For example O.S. does not allow acquiring a device that is not available. Also O.S. keeps a queue of the processes that are requested the same device Device-independent software provide a unique block size (from different disks with different sector sizes) to the higher layer.

User-Space I/O software The collection of library procedures such as count = write( fd, buffer, nbytes) scanf, printf commands Spooling. For example spool printer. Process first put the file in spool directory and daemon (the only process having permission to the printer) print the file in the directory.

Summary of I/O System

Disks A groups of magnetic disks organized into cylinders is the example of I/O devices The IDE (Integrated Drive Electronics) disks have sophisticated drives contains microcontrollers for doing some of the work of the real disk controller Disk controllers may do multiple seeks (i.e., overlapped seeks) on drives Next slide compares an early floppy disk with a modern hard disk

Disks On older disks the number of sector per track was the same for all cylinders Modern disks are divided into zones with more sectors on the outer zones than inner zones (see the next slide) To hide the details of how many sectors each track has, most modern disks presents a virtual geometry to the O.S. (see next slide)

Virtual geometry Disk with two zones

Disks The software acts as there are x cylinders, y heads and z sectors per track. Controller remaps a request for (x,y,z) onto real cylinder, head and sector The max value for Pentium is (65535, 16 and 63) means max capacity of disk with 512 bytes per sector is 31.5 GB To get around this limit logical block addressing, in which disk sectors are just numbered consecutively starting at 0, is used

Disk Formatting Before the disk can be used, each plotter must receive a low-level format done by software. It means tracks contain some number of sectors with following format The start of each sector is recognized by hardware by a certain bit pattern (named preamble) and ECC contains information that can be used for recovery

Disk Formatting After low level format each sector in the track is identified by a number. Cylinder skew means offsetting the position 0 of each track from the previous track to improve the performance (see next slide). It is done to allow the disk to read multiple tracks in one continuous operation without loosing data

Disk Formatting Reading the sectors continuously requires a large buffer in the controller But if controller has a buffer just for one sector and wants to read to consecutive sectors, after reading the first one, its data must transfer to memory. While controller transfers the first sector, the next sector will be passing under the disk head and controller can not buffer its arriving bits. This problem can be solved by numbering the sectors in an interleaved fashion when formatting the disk. See next slide

No interleaving Single interleaving Double interleaving

Disk Formatting After low-level format the disk is partitioned On Pentium sector 0 contains the partition table Finally high-level format prepare a disk for use by formatting each partition separately. It means storage administration (free list or bit map), root directory, empty file system and etc. are created for each partition

Disk Arm Scheduling Algorithm For most disks, the seek time delay dominates the other two delays (rotational and data transfer delay) so the lower layers of O.S. ( for example device driver or even controller if it accepts multiple requests) try to reduce the disk seek time Many disk drivers maintain a table, indexed by cylinder number, with all the pending requests for each cylinder By using this structure following algorithms can be used for serving the requests

FCFS If disk driver accepts request as First Come First Served (FCFS) little can be done to optimize disk seek time For example suppose while seek to cylinder 11 is in progress, new requests come for 1,36,16,34, 9 and 12. FCFS requires total arm motion of 111 cylinders

Shortest Seek First (SSF) Always handles the closet request next, to minimize the disk seek time Its performance is better than FCFS but the problem is the requests far from the middle may get poor service (not a fair algorithm) As previous example current request is for cylinder 11 and requests come for 1,36,16,34, 9 and 12. SSF requires total arm motion of 61 cylinders

Elevator Algorithm Head keeps moving in the same direction (same as elevators) until there are no more outstanding requests in that direction, then head switches the direction (it is also called SCAN algorithm) Same Example: Current request is for cylinder 11 and requests come for 1,36,16,34, 9 and 12. Elevator algorithm requires total arm motion of 60 cylinders

Elevator Algorithm Software should maintain 1 bit to know the direction. Elevator also should know whether it is going UP or DOWN Elevator algorithm is usually worse than SSF but for previous example it is slightly better

Deadlock In the Multiprogramming environment processes compete for the resources Resources can be preemptable resource that means it can be taken away from the process owning it with no ill effects (such as memory) A nonpreemptable resource is the one that cannot be taken away from its current owner without causing the computation to fail

Deadlock Deadlock can be defined as follows: A set of processes is deadlocked if each process in the set is waiting for an event that only another process in the set can cause Resource graph can be used to show a deadlock (see the next slide)

Deadlock Holding a resource Requesting a resource Deadlock

Conditions for Deadlock 1- Mutual Exclusion: At least one resource must be non-sharable. Only one process at a time can use the resource. All other requesting processes must be delayed until resource is released 2-Hold and wait: There must exist a process that is holding one resource and waiting to acquire additional resources held by other processes

Conditions for Deadlock 3-No preemption condition: Resource can not be preempted. It means a resource can only be released voluntarily by the process holding it 4-Circular wait: There must be a circular chain of two or more processes, each of which is waiting for a resource held by the next member of the chain

Deadlock Modeling Resource allocation graph facilitates viewing of system states and detecting deadlocks (see next slide). Two simple ways to avoid deadlock are presented here. A detailed discussion will come later. If Operating System decides to run all of the processes sequentially, this ordering (i.e., sequential) does not lead to any deadlocks but there is no parallelism at all If granting a particular request might lead to deadlock O.S. can simply suspend the process (not scheduling the process). See next slides

Methods for Handling Deadlock Ignoring deadlocks (Unix) (Window) Deadlock detection and recovery Deadlock prevention, deadlock avoidance by negation one of the four required conditions Dynamic avoidance by careful resource allocation

Deadlock Detection and Recovery Every time a resource is requested or released, the resource graph is updated and a check is made to see if any cycle exist. If a cycle exists, one of the processes in the cycle is killed. If it does not break the deadlock, another process is killed, and so on until the cycle is broken Another way is periodically check to see if there are any process that has been blocked for a long time. Such processes are then killed

Deadlock Prevention Attempt to prevent deadlock by ensuring that one of the 4 necessary conditions does not hold Mutual Exclusion: If no resource were ever assigned exclusively to a single process, we would never have deadlocks. For example : By spooling printer, since Daemon never requested any other resources, we can eliminate deadlock for the printer. In general this method is difficult because not all devices can be spooled. Also by spooling printer we can not eliminate the competition for the disk space that is required for spooling. This competition can lead to deadlock

Deadlock Prevention Hold and Wait: How do we ensure this condition never occurs? Each process requests and receives all necessary resources before beginning execution. Problem: they don’t know how many resources they will need until they have started running Require a process requesting a resource to first temporarily release all the resources it currently holds

Deadlock Prevention No Preemption: It means if we attack the no preemption condition we should allow a resource such as a printer taken away from a process that using it and is waiting for a non available plotter. It means this process now waits for printer and plotter.

Deadlock Prevention Circular wait: There are some methods to avoid circular wait: To have a rule and say that a process is entitled only to a single resource at any moment. If it needs a second one, it must release the first one. To provide a global numbering of all the resources. So processes can request resources whenever they want to, but all requests must be made in numerical order. See the next slide

Deadlock Prevention Numerically ordered A resource graph

Summary of Approaches to Deadlock Prevention

Deadlock Avoidance Suppose that we do not want to be restricted as to forbid existence of any one of the necessary deadlock conditions but still want to avoid deadlock. One of the way is imposing arbitrary rules on processes such as the previous example, in which by not scheduling process B the deadlock was avoided (see slide_no: 57)

Deadlock Avoidance The system must be able to decide whether granting a resource is safe or not and only make the allocation when it is safe. For example next slide shows how we can use process resources trajectories to identify safe and not safe regions. In the next slide at t B is requesting a resource. If system decide to grant it to B system will enter an unsafe region and eventually deadlock (intersection of I2 and I6). The shaded areas indicate that because of mutual exclusion system can not enter these arias. Note that printer or plotter can be used by only one process. To avoid deadlock, B should be suspended until A has requested and released the plotter.

Two Process Resource Trajectories

The Banker’s Algorithm for a Single Resource Unsafe Safe Safe

The Banker’s Algorithm for Multiple Resources