Overview of Presentation. (Greek to English dictionary) Different systems have different goals. What should CPU scheduling optimize?

Transcription

1 Overview of Presentation (Greek to English dictionary) introduction to : elements, purpose, goals, metrics lambda request arrival rate (e.g. 200/second) non-preemptive first-come-first-served, shortest-job-next tau time to complete operation (e.g. 5 ms) preemptive round robin cost of context switches, time slice length multi-queue load, overload, and graceful degradation 3/5/03-1 3/5/03-2 many of these are often used in queuing theory mu request service rate (e.g. 400/second) (p i ) time process i will need to complete its computation rho load factor ( /, e.g. 50% of capacity) when > or > 1 requests are arriving faster than they can be serviced the system is overloaded What should CPU optimize? CPU scheduler picks next ready task to run what distinguishes good choices from bad? maximize productive use of the CPU avoid idle time (when nothing is running) minimize overhead (avoid wasted computation) minimize "waiting time" time spent waiting for CPU or other resources 3/5/03-3 Different systems have different goals Time sharing fast response time to interactive programs each "user" gets an equal share of the CPU batch maximize total system throughput delays of individual processes are unimportant real-time critical operations must happen on time non-critical operations may not happen at all 3/5/03-4

2 Interactions with other Schedulers General Comments on Performance goals should be quantitative and measurable CPU scheduler decides which ready process to run if something is important, it must be measurable memory if we want "goodness" we must be able to quantify it a process on secondary storage is not "ready" you cannot optimize what you do not measure resource allocation metrics... the way and units in which we measure a process blocked for a resource is not "ready" choose a characteristic to be measured I/O it must correlate well with goodness/badness of service a process blocked for I/O completion is not "ready" find a unit to quantify that characteristic define a process for measuring the characteristic all these schedulers affect throughput and delay 3/5/03-6 3/5/03-5 it must a unit that can actually be measured Quantifying scheduler performance candidate metric: throughput (processes/second) but different processes need different amounts of time process completion time not controlled by scheduler candidate metric: delay (milliseconds) but specifically what delays should we measure some delays are not the scheduler's fault time to complete a service request time to wait for a busy resource Elements of CPU (contrast with state diagram) Ready Queue unblocks Yield (or preemption) Dispatcher Resource Manager Context Switcher Request blocks CPU 3/5/03-7 3/5/03-8

3 (Measuring CPU Scheduler Performance) process execution can be divided into phases time spent running the process controls how long it needs to run time spent waiting for resources or completions resource managers control how long these take time spent waiting to be run this time is controlled by the scheduler proposed metric time "ready" processes spend waiting for the CPU 3/5/03-9 Non-Preemptive Scheduling Scheduled process runs until it yields CPU may yield specifically to another process may merely yield to "next" process works well for simple systems small numbers of processes with natural producer consumer relationships depends on each process to voluntarily yield a piggy process can starve others a buggy process can lock up the entire system 3/5/03-10 Algorithm: First-Come-First-Serve Example: First-Come-First-Serve the simplest of all algorithms run first process on run queue until it completes or yields then run next process on ready queue until it completes or yields highly variable delays all processes will eventually be served Dispatch Order 0, 1, 2, 3, 4 Process Duration Start Time End Time Average wait 595 3/5/ /5/03-12

4 Algorithm: shortest-job-next Example: Shortest Job Next find job shortest task on ready queue run it until it completes or yields find next shortest task on ready queue run it until it completes or yields yields minimum average queuing delay this can be very good for interactive response time but it penalizes longer jobs (is this OK?) Dispatch Order 4,1,3,0,2 Process Duration Start Time End Time Average wait 305 3/5/ /5/03-14 A closer look at SJN How practical is SJN? how can we know how long a job is going to run? How fair is SJN? the smaller jobs will always be run first, new small jobs cut in-line, in front of older longer jobs will the long jobs ever run? only if short jobs stop arriving... which could be indefinite this is called starvation it is caused by discriminatory 3/5/03-15 Preemptive Scheduling a process can be forced to yield at any time if a higher priority process becomes ready perhaps as a result of an I/O completion interrupt if running process's priority is lowered perhaps as a result of having run for too long, detected when processing a clock interrupt enables enforced "fair share" introduces gratuitous context switches creates potential resource sharing problems 3/5/03-16

5 Implementing Preemption need a way to get control away from process e.g. process makes a system call, or clock interrupt consult scheduler before returning to process if any ready process has had priority raised if any process has been awakened if current process has had priority lowered scheduler finds the highest priority ready process if current process, return as usual if not, yield on behalf of current process and switch 3/5/03-17 Algorithm: round-robin Goal - fair share all processes offered equal shares of CPU all processes experience similar queue delays all processes assigned a nominal time slice each process is scheduled in turn runs until it blocks, or its time slice expires then next process is run after last process, go back around to first 3/5/03-18 Example: Round Robin Dispatch Order: 0, 1, 2, 3, 4... (50 ms quantum) Process Length Start 2 nd 3 rd 4 th 5 th 6 th 7 th 8 th finish Average wait to start 100 Average wait to finish 850 Context switches 28 (5x more than non-preemptive) 3/5/03-19 The cost of a context-switch system context switch stack, non-resident process description execution state registers, PC, PSW address space map-out old process, map-in new process general overhead dispatch trap, run scheduler, return losing instruction and data caches 3/5/03-20

6 What is optimal Time Slice length? CPU share = time_slice * slices/second 2% = 20ms/sec = 2ms/slice * 10 slices/sec 2% = 20ms/sec = 5ms/slice * 4 slices/sec context switches are far from free they waste otherwise useful cycles they introduce delay into useful computations natural re interval when a process blocks for resources or I/O ideally, fair-share would be based on this period Priority Computation CPU scheduler always picks highest priority key is how priority is computed perhaps based on externally supplied priority associated with the application being run associated with owning user perhaps based on system supplied priority associated with particular system services perhaps based on execution history priority goes down the longer you have been running priority goes up the longer you have been waiting 22 3/5/03-21 only time-slice-end if process runs too long 3/5/03-22 Multi-Queue Scheduling (Multi-Queue Scheduling) share scheduler 20% 50% 25% 5% real time queue ts max = #ts = short quantum queue ts max = 500us #ts = 10 medium quantum queue ts max = 2ms #ts = 50 one time slice length may not fit all processes create multiple ready queues Short Quantum Queue for processes that finish quickly short but frequent time slices, optimize response time Long Quantum Queue for processes that run longer longer but infrequent time slices, minimize overhead different queues may get different shares of the CPU long quantum queue ts max = 5ms #ts = start all processes in short quantum queue move them based on their observed behavior 3/5/ /5/03-24

7 Mechanism/Policy Separation built-in scheduler mechanisms always run the highest priority process formulae to compute priority and time slice length user specifiable policy per process parameters initial, relative, minimum, maximum priorities queue in which process should be started (or resumed) per queue parameters maximum time slice length and number of time slices priority change per unit of run time and wait time Performance: throughput vs. load offerred load CPU share (absolute or relative to other queues) 3/5/ /5/03-26 throughput ideal typical (Why throughput falls off) dispatching processes is not free it takes time to dispatch a process (overhead) more dispatches means more overhead (lost time) time spent dispatching not available to run processes how to minimize the performance gap minimize the number of dispatches longer time slices or limit number of ready tasks this phenomenon will be seen in many areas Performance: response time vs. load delay/response time typical ideal offerred load 3/5/ /5/03-28

8 (Why response time grows w/o limit) response time is a function of the server & load how long it takes to complete one request how long the waiting line is length of the line is a funciton of the server & load how long it takes to complete one request the average inter-request arrival interval if requests arrive faster than they are serviced the length of the waiting list grows and the response time grows with it 3/5/03-29 playing near the edge of the cliff can a system safely run near its capacity? when request arrival rate approaches service rate when approaches, and approaches 1 what if we can service a request in 10ms, and... a new request arrives every 11ms? a new request arrives every 9ms? what if requests arrive (on average) every 10ms? sometimes they arrive sooner and sometimes later sometimes we will be overloaded... will we recover? 3/5/03-30 Response time below capacity service time 10 inter-arrival time 11 Response time above capacity service time 10 inter-arrival time 9 Request Arrives Starts Completes Resp Time /5/03-31 Request Arrives Starts Completes Resp Time response time includes time spent waiting in line and the line gets ever longer 3/5/03-32

9 Performance: Graceful Degradation When is a system "Overloaded"? when it is no longer able to meet service goals What can you do when overloaded? continue service, but with degraded performance maintain acceptable performance by rejecting work resume normal service when load drops to normal What can you not do when overloaded? allow throughput to drop to zero (stop doing work) allow response time to grow without limit 3/5/03-33 for the next lecture read chapter 8-8.2, there will be a quiz on this material next lecture critical sections and synchronization critical sections atomic instructions and exclusion semaphores will be discussed in the following lecture 3/5/03-34 key points goals and responsibilities of scheduler measuring scheduler performance throughput and response time, ideal vs. real mechanisms and algorithms preemptive, advantages/disadvantages starvation, how and why it happens, how to prevent optimal time slices, what are they and why priority based, multi-queue 3/5/03-35