06 February 2002 Operating Systems Read: Nutt, Chapter 6 & 7 Administrivia ------------- Project 1 due on Monday, before midnight Project writeup: document the choices you made what data structures did you have to protect? how did you protect them? what was the behavior of the program: e.g., how did the threads behave how did the behavior change when you added more threads? Finishing Devices and starting Processes and Scheduling ------------------ Disk Scheduling - optimize time for operations ---- Can view storage as one, linear sequence of blocks Requests = 23, 87, 36, 93, 66 FCFS - service requests in order they arrive may have long seek times may have poor performance probably ok under light load, but quickly degrades FCFS: (75), 23, 87, 36, 93, 66 52 + 64 + 51 + 57 + 27 = 251 SSTF - shortest seek time first next = shortest seek time from current position lower mean waiting time possible starvation of blocks at extreme non-optimal, especially under light load. SSTF: (75), 66, 87, 93, 36, 23 9 + 21 + 6 + 57 + 13 = 106 steps Note: seek time not linear - acceleration/deceleration SCAN/LOOK: (elevator algorithm) disk head sweeps back and forth over all cylinders, changing direction only at the extremes. LOOK is same as SCAN except that it changes direction when there are no more requests to be satisfied in the current direction. does not discriminate (starve) individual requests gives non-uniform wait time for requests a request to track 0 must wait for a scan from track 1 to track N and back; a request for track N/2 need only wait for half as long. Scan: (75), 87, 93, ((99)), 66, 36, 23 12 + 6 + 6 + 33 + 30 + 13 = 100 steps Look: (75), 87, 93, 66, 36, 23 12 + 6 + 27 + 30 + 13 = 87 steps Note: if the disk head starts at an extreme of the surface and the request queue is static (within a scheduling interval), SCAN is equivalent to SSTF. Note: simulations show that under heavy load, SCAN and SSTF have similar performance. C-SCAN/C-LOOK: similar to SCAN/LOOK, except that the head moves back to track 0 from track N. (C is for "cyclic") - exploit "homing" gives more uniform wait time for individual requests Circular Scan: (75), 87, 93, ((99)), 23, 36, 66 12 + 6 + 6 + home + 23 + 13 + 30 = 90 + home Circular Look: (75), 87, 93, 23, 36, 66 12 + 6 + home + 23 + 13 + 30 = 84 + home For lightly loaded disks, use FCFS or LOOK. For heavily loaded disks, use C-LOOK. Note that all the above discussion addresses the best way to access data once we know its physical address. A related (and perhaps more interesting) problem is to figure out which physical locations to use for which data. This is a file system topic. Coming up. ============================= RAID (redundant arrays of inexpensive disks) Fairly new idea (last dozen years or so). Improves disk bandwidth, though not latency. Spreads data across multiple disks so that they can all transfer in parallel. Scattering across disks may be at the bit or word level (as in the "data vault" for the TMC Connection Machine 2), or at the block level (as in the RAID devices now offered by many manufacturers). You can now buy RAID devices for personal computers! Note that block-level interleaving is a win only if you want to read more than one block at a time. Big problem with RAID: failures. If you have 50 disks, each of which has a .001 chance of failing this week, and if failure rates are independent, then the odds that all your disks stay up is .999^50 ~= .95. That's one chance in 20 of a failure. Without redundancy, that single failure takes a piece of *every* file. Different practical RAID schemes introduce redundancy in different ways. Data vault uses a Hamming code to represent each 32-bit word with 38 bits spread across 38 disks, with single-bit recovery. Simplest redundancy is mirroring; fancier schemes use more space-efficient parity encoding. Maintaining parity sectors is expensive if you read and write single sectors. It's not bad if you read and write whole sector groups at one time. RAID 0 data striping, no redundancy high performance, noncritical RAID 1 mirrored disks (100% overhead) good read (can read from closest head), moderate write cost RAID 2 data-vault style: nibble-level striping, synchronized writes poor read/write rate, excellent transfer rate need synchronized heads not really used, too expensive RAID 3 block-level striping, parity disk, synchronized writes can do one bit correction if drive fails poor read/write rate, excellent transfer rate need synchronized heads RAID 4 like RAID 3, but non-synchronized excellent read, fair write RAID 5 scattered parity, avoid bottleneck to write parity disk good for high request rate, read-intensive data lookup reconstructing after a failed drive is complex other extensions from various vendors, e.g., block-interleaved dual distributed parity Process Management ------------------ Terms processor - CPU (physical resource) multiprocessing - using more than one physical processor virtual processor - abstraction of a (nicer?) processor multiprogramming - multiplexing virtual processors on a physical processor process - the execution of some code. Depending on author, may or may not entail extra baggage like an address space and file descriptors thread - like a process, but definitely doesn't entail all the baggage Processes in Operating Systems Used to model user-level programs various activities within the kernel (sometimes) asynchronous devices and their interrupt routines Process components: program - might be shared among multiple processes data resources process descriptor register contents state (blocked/ready) address mapping details memory state pointer to stack resources acquired resources pending Process States (draw transition diagram) running - the process is executing on some CPU ready - the process is able to execute, but must wait for a CPU blocked - the process is waiting for some action (eg, I/O) to occur transitions running to blocked wait for something that hasn't happened yet (synchronization) blocked to ready completion of awaited event running to ready preemption ready to running dispatch (sometimes) ready to blocked external action, e.g. by shell or debugger