I/O DevicesThree categories:Human Readable (display, keyboard)Machine Readable (disk)Communication (modem, network)Other Differences:Data Rate (Figure 11.1, page 475)Keyboard80 b/sCD-ROM6 Mb/sVideo display1Gb/sApplicationDisk requires file system supportComplexity of ControlKeyboard driver simpler than disk driverUnit of Transfer (byte, block)Data Representation (char set, parity)Error Conditions

I/O TechniquesProgrammed I/OProcessor issues I/O command, waits for the operation to completeOften handles I/O transfer detailsInterrupt-Driven I/OProcessors issues I/O command, then proceeds to another process or threadDevice interrupts the CPU when the data is ready to be moved to memoryDirect Memory Access (DMA)Processor issues I/O commandDevice transfers data to/from memory (CPU will wait for memory)Device interrupts the CPU when the I/O transfer is completed

Evolution of I/OCPU directly controls deviceSeen in some microprocessor devicesI/O module (i.e., serial port chip)CPU uses programmed I/OAdd InterruptsMore efficient No polling neededI/O module supports DMADevice can move a block of data without involving the CPUI/O ProcessorI/O device enhanced with a set of I/O-specific instructionsCPU creates I/O programI/O Module with memoryModule becomes a computer of its ownMinimal CPU involvement

DMABlock structure (figure 11.2, pg. 477)Data count (# of bytes/words)Data register (data to/from device)Address register (memory location)Control logicStructure of operations:CPU initializes DMA unitInform unit if this is a read or writeSet the address of I/O deviceAddress of memory to read/writeAmount of data to transferDMA device performs transferSteals memory cycles from CPUThese may occur in the middle of an instruction (figure 11.3, pg. 478)DMA device interrupts CPU at endReduces CPU involvement, # of cycles for large transfersDMA can transfer data in one cycleCPU would need cycle to get from device, storeEach interrupt also has overhead

DMA ConfigurationFigure 11.4, page 479

I/O Design ObjectivesEfficiencyI/O can be a bottleneckSwapping is used to increase number of ready processesRequires I/O activity to do thisMajor emphasis is on disk efficiency due to its importanceGeneralityEasier to handle devices uniformlyHow processes view I/O devicesHow O.S. manages I/O devicesBecause of differences in devices, it is hard to achieve true generalityCan use a hierarchical, modular approach to hide I/O detailsProcesses see open/read/write/close for all devices

Logical StructureHierarchical structureDivide levels by complexity, time scale, and level of abstractionLow levels may work at nanosecond time framesSimple structure (fig 11.5, pg. 482)

I/O OrganizationLogical I/O Think of the device as a logical resource (open, read, write)Directory Management Convert file names to identifiers that reference a fileFile System Deal with logical structure and open, read, write, also permissionsPhysical Organization Convert logical references to storage addressesDevice I/O Convert operations and data into I/O instruction sequencesMay use buffering to improve speedScheduling and Control Actual queuing and scheduling of operationsThis level handles interrupts, status

I/O BufferingI/O operations from user memory space creates problemsThe pages holding the data must remain in main memoryLimits choices O.S. can makeCannot completely swap out process, or deadlock may resultProcess waiting for I/O to completeI/O waiting for process to be swapped inMay want to read in advanceMay want to delay writesCombine writes when updating diskBuffering MethodsFigure 11.6, page 484:

Single BufferingI/O device transfers data to a system buffer, then O.S. copies data to userAs soon as transfer is completed, try to read the next block in advanceHopefully that block will be used nextUser process can be working on one block while the next is being readBlock transfer time: max[C,T]+MC = time to compute, T = time to do I/O, M = time to transfer to bufferNote: with no buffering, time is C+TO.S. must track which buffers are assigned to user processesDont want to swap to a device if we are waiting on that device for I/OAble to swap processes without interfering with I/O operationsFor character-I/O, can use buffer for byte buffering or line bufferingProducer/Consumer type problem

BufferingDouble BufferingUses two system buffers, read into one buffer, copy data to user from the otherBlock transfer time: max[C,T]max[C+M,T]? Account for move timeCan do transfer while next I/O startsCircular BufferingSimilar to double buffering, but have multiple system buffersHelps handle I/O burstsSummaryBuffering helps smooth out peaks in I/O useDoesnt improve sustained I/O rateGenerally helps in multiprogramming systems

Disk PerformanceMuch slower than memoryTypical disk speed: 4-10ms (10-3s)Typical memory speed: 1-10ns (10-9s)Performance measuresSeek Time Time to move the headsApproximation: (c depends on drive)# of tracks*c + startup/settle time Rotational Delay Waiting for the correct sector to move under the headAverage 1/2 rotationHD: 5400rpm 5.6ms, 10000rpm 3msFloppy: 300 rpm 100msTransfer Time Actual time needed to perform the read or writeAccess Time Sum of seek time and rotational delayTime depends on locality (page 489)Assume 10ms average seek, 10000 rpm, 320 sectors/track, 2560 sectors in the file (1.3MB)Sequential reads = 0.082sRandom = 33.328s

Disk SchedulingIf we have a number of requests, what order do we do them?RandomSelect a random request to do nextUseful for comparisonsFIFODo in the order they arriveFair in that all requests are honoredPoor performance if requests are not clusteredEspecially true in multiprogramming systemsPriorityDo operations for high-priority processes firstDisk utilization not the top goalUsers may try to exploit priorities

Disk SchedulingLIFO (Last-In First-Out)Always take the most recent requestHope to catch a sequence of reads at one timeRuns risk of starvationSSTF (Shortest Service Time First)Select the read closest to the current track nextRequires knowledge of arm positionAlso has risk of starvation SCANArm moves in one direction, meeting all requests en routeIf no more requests, switch directionsBias against track just traversedWill miss locality in the wrong direction

Disk SchedulingCSCANAlways scan in one directionIf no more requests, move to far end and start overReduces time for requests on edgesN-step ScanPrevent one track from monopolizing diskHave subqueues of size NUse SCAN for each subqueueFSCANWhen one scan begins, only existing requests are handledNew requests are put on a secondary queueWhen a scan ends, take the queue entries and start a new scan

Disk SchedulingRequests (in order made):55, 58, 39, 18, 90, 160, 150, 38, 134Assume the head is currently at 100Figure 11.8, page 490

RAIDRedundant Array of Independent DisksIf the data is on separate disks, we can issue parallel commandsThis can be individual requests or a single large requestStandard levelsTable 11.4, page 495Common characteristicsViews a set of physical disks as a single logical entityData is distributed across the disks in the arrayUse redundant disk capacity to be able to respond to disk failureAddresses the need for redundancyMore disks more chance of failure

RAIDRAID 0Use multiple disks so a request will request data from multiple disks that can seek/transfer data at onceAlso may balance load across disksDoes not use redundancy

RAID 1Mirror data: reads can be serviced by either disk, writes update both disks in parallelFailure recovery easy

RAIDRAID 2Parallel access All disks participate in each I/O requestUse a Hamming code to correct single-bit errors, detect double-bit errorsOnly used if high error rates are expected

RAID 3Only a single parity strip is usedParity = data1 xor data2 xor data3 ...Missing data can be reconstructed from the parity strip and remaining data stripsCapable of high data rates, but only one I/O request can take place at a time

RAIDRAID 4Each disk operates independentlyParity strip handled on a block basisParity strip must be updated on each writeParity disk tends to be a bottleneck

RAID 5Like RAID 4, but distribute parity

RAID 6Use two different data check methodsCan handle a double-disk failure

Disk CacheSimilar concept to memory cacheUse main memory to hold frequently used disk blocksCan afford more complex algorithms due to the time factors involvedHandling a requestIf the data is in cache, pass it to the user (copy or use shared memory)If it is not in cache, read the disk and add it to the cacheReplacement algorithms:LRU Can keep a list and determine the one not used for most timeLFU (least frequently used)Account for how often it is usedWatch out for burst of uses, then idle

Frequency-BasedFirst Version:Two sections: new and oldIncoming blocks given count=1Cache Hit:Move the block to the front of the new sectionIt it was in the old section, increment count (else leave count unchanged)Replace the block in the old section with the smallest countProblem:A block referenced in a burst will stay in the new section with count = 1When moved to old section, will tend to be replaced fairly earlyThis may be a poor choice to remove

Frequency-BasedRevised Version:Three sections: new, middle, oldBlocks age new middle old Cache Hit:Move the block to the front of the new sectionIt it was in the old or middle sections, increment count (else leave count unchanged)Middle section allows blocks a change to build up a reference count before being replacedReplacement Can be on demand or preplannedPreplanned allows disk writes to be clustered (hope for better performance)

Unix SVR4 I/OEach I/O device associated with a special file (/dev/xxx)Use ordinary read/write calls to access the deviceDevices separated into character and block devicesI/O Structure (figure 11.14, pg. 506)

Character QueueUsed for character-orientated devicesProducer/Consumer modelData from the device is written to a queueProcess reads data from the queueData destroyed as it is read

SVR4 Buffer CacheServes as a disk cacheFree List Available slots/buffersDevice List Associated with a deviceDriver I/O Queue Waiting or performing I/OUse a hash table to quickly find the buffer corresponding to a particular device and block (figure 11.5, pg. 507)Uses LRU for blocks in the queueOrder kept by the free list order

UNIX DevicesUnbuffered I/OSend data directly to the processFaster, but process locked into memory Devices suitable for unbuffered I/O or the buffer cache:Disk DrivesTape DrivesDevices suitable for Character Queue:TerminalsPrintersDevices suitable for unbuffered I/O or the character queueCommunication Lines

Windows 2000 I/OI/O Manager (Fig. 11.16, pg. 509)Responsible for all system I/O and providing a uniform interface

Cache ManagerHandles caching for I/O subsystemCan dynamically vary the size of cache depending on available memoryLazy write Only cache updated on a write (not disk)Lazy commit Similar, but for transactions

NT I/OFile System DriversTreated as an ordinary device driverRoutes messages for particular volumes to the proper driverNetwork DriversIntegrated networking capabilities and support for distributed applicationsHardware Device DriversAccess hardware through NT DLLsRoutine names are the same for all processors (better portability)Synchronous vs. Asynchronous I/OSynchronous: Application blocks until I/O finishesAsynchronous: Application continues and is informed of completion later

Asynchronous I/OApplication makes request and proceedsWays to signal completionSignal a device kernel objectSimple to handleCannot distinguish multiple requests regarding the same fileSignal a event kernel objectCan create a separate object for each requestAlertable I/OI/O manager places results in APC (asynchronous procedure call) queueI/O completion portsUse a pool of threads to handle requestsRAIDHardware Done by disk controllerSoftware System combines space