Lecture: Wednesday, January 26, 2005 Announcements: - CSUA UNIX help session today - Course reader NACHOS part is available at Copy Central for about $13, the second part will be available soon. - If you want a text book, buy it soon before the student store returns its copies - Read the syllabus and handouts before asking questions regarding syllabus material. - Sign up for lecture note taking if you haven't done so. - Section 103 will now be held from 5-6 in 320 Soda TOPIC: CPU Scheduling continued Goals for Scheduling Discipline What is a goal? What is being optimized? 1. efficiency of resource utilization - (ie make sure CPU and disks are busy) 2. minimize overhead (between swaps) 3. minimize response time - Response Time: time it takes the computer to respond when you ask it to do something 4. maximize throughput - Throughput: Number of jobs completed per second 5. provide guaranteed fraction of machine to specific groups 6. minimize the number of waiting process or interactive users - those are not necessarily the same, users waiting are more impatient then those not at the terminal 7. get short jobs done quickly 8. Avoid starvation - Starvation is when a process gets very little service, it just sits there and waits and every once in a while it gets a little CPU time, or maybe not (i.e. the scheduling algorithm keeps putting it at the end of the queue) - rho is the load on the system - if rho >1 the workload is more than the CPU can accomplish (i.e. there will be jobs that will not get serviced). Real "starvation" occurs here, when rho<1, this is also called "hunger". - if rho < 1 then eventually every job will get serviced, though some may wait a long time - rho = 1 is an unstable situation, in practice does not occur. 9. minimize variance of response time - (i.e. make runtime predictable) 10. satisfy external constraints - (i.e. who's paying for it, the importance of the jobs) 11. meet deadlines - a deadline is a deadline, it doesn't matter if you're trying to minimize Queue length, because deadline is a dealine. 12. graceful degradation under overload - Real world example: Freeway onramp lights, which control access to prevent gridlock, - so you'd like the system when it is overloaded not to come to a shuddering halt 13. Provide Fairness?? NO! - The problem with fairness is it is a psychological concept and means nothing to a computer. - First Come First Serve and Round Robin are both fair, but they don't have the slightest relationship to each other - so fairness cannot be optimized! None of the above is the real goal: REAL GOAL!! = Maximize user satisfaction, (psychology) - ultimate goal of scheduling algorithm is to keep user population happy - users aren't processes, they are the people who generate the processes - minimize complaints, but remember, not all complaints are equally valid Since this is not a psychology class and we aren't going to use users to evaluate the scheduling algorithm, we are going to use other criteria, as objectives: Measureable Objectives: 1. Minimum Flow Time - Definition: The time a job takes from when it arrives to when it is done; the time it takes to flow through the system - minimizing flow time is minimizing the average flow time over all the jobs 2. Secondary goal = minimize flow time/ service time, - where service time is the time a job requires to complete and flow time is arrival time – completion time. - generally speaking f(i)/s(i) should be proportional (ie. Short jobs take less time than long jobs) - This is a psychological expectation, if people put in a lot of work they expect it to take a longer amount of time. Typical External Constraints 1. Fixed Priorities - determined administratively or by purchase - (Ex. At Livermore you can pay for priority, so if its going to be run overnight give it low priority, if you want it now, pay for higher priority) - pay n times the going rate of CPU time and get n time the priority 2. Fixed Fraction of Machine - (ex. Your department paid for 25% of it, you expect to use 25% of the CPU cycles) 3. Realtime - i.e. not CPU clock, but clock on the wall - ex. shooting down missile before it hits you. - ex. Assembly line: car going down line, if the welding arm does not get there before car moves to next station, it does not weld the door, and the door falls off. (must be accurate timing to work) Question: How do you measure flow and service time? Answer: - Flow time is arrival to departure - Generally, you don't know service time in advance because it is dependent on the system, but it is an invariant based on the scheduling algorithm - In real world, don't know either f(i) or s(i) - ex. Throughput on a bridge: don't know how fast people are driving or how long it will take them , but want to optimize both. Note: For Scheduling you can analyze simple cases, in real system there are more things going on, like I/O devices, page faults, etc. So can analyze simple cases and use them as an approximation for complex cases. Open vs. Closed Systems - Open System = one in which the arrival rate of customers in the system is unaffected by the number in the system (in queue) mu lambda ------------ -----------> | SYSTEM | -----> ------------ * Arrival rate not affected by what is going on in the system * lambda = arrvial rate * mu = service rate - Real world example: DMV = almost an open system in practice (almost because # of people actually is finite) but the fact that the line gets longer doesn't really affect the number who come through the door - Closed System = one in which the total number of customers (in the system + in the world) is constant so the more that are in the system, the fewer that can be arriving (because they are already in the system) ----------- <---- | WORLD | <---- | ----------- | | | | ----------- | ----> | SYSTEM | ----> ----------- * Amount of arriving work is depenedent on the system. - ex. if a user is waiting for a respose it cannot send another process to the system - Example: Everyone issues a command and waits for a response/waits for previous thing to come back before issuing next command. Why do we care? How does it affect throughput? - Throughput is number of jobs completed per second - if rho<1, in an open system, throughput is invariant with regard to the scheduling algorithm (An open system does not affect throughput) - Throughput in a closed system varies with the scheduling algorithm, because if sometime is waiting, it has less time do the next step. lambda arrival rate Rho = -------- = offered load = ---------------- mu service rate 1/lambda = mean time between arrivals 1/mu = mean service time if rho > 1 more work is arriving than system can accomplish if rho < 1 system can complete it all *When add overhead can't do mathematical analysis, so mu doesn't include overhead, use simplifications. HW1 is slightly more complicated, but still does not add features like I/O devices. * may or may not be a good idea to try and optimize throughput User Characteristics - Willing to wait proportional to how long a job should take. - Like predictability - Users at the terminal are impatient Note: For Scheduling use Figure 1 from last lecture, because figure 2 is too complex for scheduling. Scheduling Algorithms: What is the simplest scheduling algorithm? FIFO also called FCFS (First come first serve) Properties: - jobs get in line, run in order they come, run until finished - (usually `finished' means `blocked' if one process is blocked (ie waiting), another can run, and the first goes to the end of the queue when it is ready again. Advantages: - fair, simple, low overhead(no switching between jobs) - lowest variance of f(i), when average over all the jobs FIFO gives least variation of flow time Disadvantages - one process can monopolize the CPU - short jobs wait for long jobs - little resource sharing (jobs that need other resources could have gone through CPU earlier then use those why another is using CPU) - high variance for flowtime/servicetime (i.e. short or long jobs take the same time to get through) Are there short jobs and long jobs? Job Characteristics - Job runtimes are highly skewed - The expected time that a job has remaining to run is an increasing function of the time it has already run. Fig.1 | | | | lots of short jobs | \ few long jobs Prob | \ | \ | ---------- |___________________ Run time r(t) Fig. 2 | | Expected time | / to | / Completion | / E(t) | / |------/ |___________________ time run so far t (elapsed serive time of job) * the longer a job has been running the higher probablity it will run even longer * In a sense it is counter intuitive, normally think the more you do it, the less is left to do, when raking the lawn, can tell when half done. But here, you don't know how long it is supposed to take, only know how long it has run so far. Probablistically, if a job has run for a long time, it will probably still run for a longer time. * Ex. You ask your roommate to buy milk, the next day no milk, after 5 days still no milk, so your expectation of how many days you'll have to wait for the milk as gone up (it will still be a few days before you have milk) - The expected time to the next I/O is an increasing function of the time since the last I/O, same is true for page faults, and traps or interrupts - This is averaged over lots of jobs, may not happen for a specific one. Expected time to competition E(t) E(t) = Integral from t -> Infinity of (x - t)r(x) dx ----------- 1 - R(t) r(x) = runtime distribution R(t) = cumulative distribution This is the basis for everything we say about whats a good scheduling algorithm: We don't know how long they are going to run, but we know if they've run for a while chances are they will run for a while longer, so we'll limit how long they run before we switch another job in. Solution: Limit the maximum amount of time that a process can run without a context switch (ie switch caused because job ends). This is called TIME SLICE. Obvious algorithm which uses this idea = Round Robin Round Robin (RR) Properties: - each process run for the time slice, then moved to the end of the queue - each process gets equal share of the CPU - most systems use some variant of this - choose Time Slice carefully - if it is too long, limit at slice size goes to infinity, RR becomes FCFS - if it is too short, too much time is wasted on the overhead. Advantages - short jobs are done first, "fair" (but different from FCFS), reasonably simply, low variance of Flow time/service time = f(i)/s(i) - takes literately longer for longer jobs - no starvation Disadvantages - high overheads - not as good as other schemes Question Answer: Sometimes you may know the runtime/service time, Ex. for banks that repeatedly do the same transaction, (ex. Get the balance) you may know how long that will take. Banks have many such short transactions and may have the rare long search-type job. Generally, though you may not know how long a job needs to run. Question: Does any OS have more than one Scheduling Algorithm? Answer: "Not to my knowledge". Most OS have a scheduling algorithm more complex than these, but some variation of these. They do a series of simulations to tune it and create their own algorithm. Complexity can be added, we're doing simplified versions. Round Robin Cont. - Round Robin can be made to implement priorities, give different priorities to different time slices. - No job takes zero time. So want quantum to be big enough so really short jobs get done in one cycle. Round Robin works well because runtimes are highly skewed, if not RR is not worth much. Ex. 10 process require 100 times units. Time switch every 10 time units Each job take avg. 950 time slices First job finished at 910 time slices Last job finished at 1000 times slices FIFO/FCFS average time = 550 time slices to finish RR is fair but uniformly inefficient here. FIFO is better because each finishes when done, whereas RR takes the whole time. When FIFO has all but one job left RR is only completing all the jobs, and hasn't finished any. Again, this is simplified; we aren't taking into consideration the time it takes to get into memory/ overhead. Underlying basis for future scheduling Algorithms = runtimes are skewed. GOAL: Minimize flow time This is the same thing as minimizing the average number of customers in the system. This is because of Little's Formula: (proved first by J.D.C Little) Little's Formula: N = lambda * F where N = mean number of users in the system F = mean flow (waiting) time Lambda = arrival rate of users 1/lambda = mean time between arrivals always assuming rho< 1 (ie system isn't overloaded) Also could be L = lambda * W Where L = mean number of customers in the queue W = waiting time = flow time excluding service time What does this mean for scheduling? - To minimize flow time, also minimize the number of users in the system, or prioritize small jobs. - Obvious solution for this is Shortest Job First (Shortest Processing Time) Shortest Job First Properties: - Run the shortest job first and to completion - This reduces N (# of customers) => reduces flow time Advantages - It is optimal (ie gives the minimum average flow time) if don't have preemption (once you start a job it finishes) and no knowledge of future arrivals. Disadvantages - requires future knowledge -- how long job should take (service time) - could do better if can use preemption, because if a short job come in the middle it must wait until current one is done - high variance of flow times, long jobs wait a long time Therefore, try using preemption: Shortest Remaining Processing Time (SRPT) Properties - Basically is Shortest Job First with preemption (i.e. if a shorter job comes in switch to the shorter job) Advantages - this is the most optimal scheduling algorithm, it will minimize the flow time through the system Disadvantages - requires future knowledge - overhead due to preemption (but only one per job, because each job arrives once) - long jobs wait, high variance of flow time Preemption: (ex. An arrival) - in general, when something interrupts something that is running - SRPT never has more preemptions than jobs But SRPT requires future knowledge, so... Remember: The longer a job has run the greater the chances that it will still run for a long time. So... Shortest Elapsed Time Properties: - run the job that has used the least processing power so far because the less time a job has been processed, the further to the left it is on the curve Fig. 1, so the less it probably has to complete. If all we know is how long its run, then the assumption is that the job that has run the least will be the first to complete. - Needs a quantum to determine how long it should run before checking if there is a shorter process. Advantages - permits short jobs to be done quickly - variance of flow time / service time is reasonably low Disadvantages - if not careful, can have high overhead for switching - if runtime distribution not highly skewed, very bad! (if all have the same runtime, they all wait for each other) - long jobs wait, high variance of flow time Announcement: Recomp is hiring. Variety of jobs, $14-19/hour, flexible hours.