11 February 2002 Operating Systems Read: Nutt, Chapter 7 ------------------------- Scheduler - manage the ready queue, which proc gets CPU next manage the context switch can swappted voluntary or involuntary involuntary - interrupt handler manages swap voluntary - process releasing manages the swap release CPU when making a resource request Can rely on processes to voluntarily yield the CPU to the scheduler But may not result in equitable sharing For more equitable sharing, create an interval timer device when timer fires, an interrupt is raised interrupt calls the scheduler to reschedule the processor result: preemptive scheduler scheduling performance goals: cpu utilization: how busy is the cpu -- don't want it idle, or otherwise wasting time. Might be idle if you don't context switch on I/O; might waste time if you context switch too often (since that induces overhead) throughput (especially important for batch systems): how many jobs go thru the system per unit time response time (especially important for time-sharing systems): how long the user has to wait for trivial operations (e.g. character echoing). Both latency and variance matter; human-factors studies tend to indicate that latencies are indistinguishable under half a second (maybe a tenth of a second for echoing), and that low variance above half a second is often more important than low latency. turnaround time (especially important in batch systems): average time each job is in the system -- how long you expect to wait to get your results. fairness We can't meet all goals at once. For example, utilization and response time conflict directly. Maximum utilization comes from a RUN-UNTIL-BLOCK policy. Good response time requires a PREEMPTIVE policy -- frequent context switches. Types of Scheduling long-term: deciding which job to accept into the system long-term scheduling is important for batch systems, but irrelevant for time-sharing medium-term: deciding which running process must block for resources (NOT synchronization) swapping is a form of medium-term scheduling. so are various deadlock-avoidance algorithms (e.g. banker's) short-term: deciding who runs among the processes that can run This is next ---------- Optimal scheduling: given a set of processes with known amounts of proc time select optimal by enumerating all not practical: new processes do arrive running time not known takes time to compute optimal O(n^2) criteria wait time - time process waits to receive first unit of service turn-around time - time to complete after it has been made ready - represents user's waiting time for a batch proc throughput rate - jobs per minute process scheduling model ignores wait time for resources Common policies --------------- Simplest run-until-block policy: FIRST-COME-FIRST SERVED (FCFS) Guarantees eventual service. Sometimes interpreted (by some authors) to mean you don't switch on I/O. Better interpretation is: when the current job blocks, switch to the job that's been waiting longest for the CPU. Simplest preemptive policy: ROUND ROBIN Process runs for QUANTUM time t then it is interrupted and moved to the tail of the ready queue quantum too high: RR = FCFS. quantum too low: too much time context switching. small optimization: for procs w/ very burty CPU access will not use whole quantum put into auxiliary queue after IO release - higher priority new quantum time is quantum-used Optimal policy for expected turnaround time: SHORTEST JOB FIRST (NEXT) provably optimal for average expected turnaound time avoids "convoy effect" Requires that you know time to completion. not typicall known. might know in commercial transaction processing Might starve large procs. Many fancier schemes use some notion of PRIORITY run the process with the highest priority . If several processes are tied for first, do them round-robin. Priorities can be based on: degree of interactiveness amount of last quantum used (optimization from above) user id Processes can starve lots of high priority processes arrive, lower ones never execute one sol'n is to age a process - increase priority as it gets older The art of compromise: MULTIPLE QUEUES, MULTI-LEVEL SCHEDULING not just one pool of procs, but multiple classes each class has its own scheduling queue and policy master process manages these multiple queues simple classes: foreground vs background compute vs I/O bound diff respons time requirements some soft-realtime systems one concern - high pri. waiting for resources held by lower pri. PRIORITY INVERSION sol'n: lower priority temporarily inherits higher priority A relatively recent entry: LOTTERY SCHEDULING (1994 OSDI) Carl A. Waldspurger, William E. Weihl MIT Laboratory for Computer Science give processes lottery tickets # proportional to importance of job randomly select ticket and give processor to holder important processes get more CPU no need for aging probabilitistic behavior can be used preemptive or non-preemptive keep list of procs. each proc remembers number of tickets scheduler remembers num tickets passed out (N) to schedule, randomly select num 1..N, i traverse list, adding up #'s of tickets until find proc with the ith ticket No number per ticket if few tickets, value is higher. value changes as processes come and go can transfer tickets among procs why? someone holding lock you want - give them your tickets give each user fixed # tickets, they reallocat them to their processes to give relative importance similar to nice + nice value decreases priority - nice increases priority