Unformatted text preview:

CS 372: Operating Systems Mike Dahlin 1 02/24/11 Lecture #3: CPU Scheduling ********************************* Review -- 1 min ********************************* Deadlock ♦ definition ♦ conditions for its occurrence ♦ solutions: breaking deadlocks, avoiding deadlocks ♦ efficiency v. complexity Other hard (liveness) problems  priority inversion  starvation  denial of service ********************************* Outline - 1 min ********************************** CPU Scheduling • goals • algorithms and evaluation Goal of lecture: We will discuss a range of options. There are many more out there. The important thing is not to memorize the scheduling algorithms I describe. The important thing is to develop strategy for analyzing scheduling algorithms in general. ********************************* Preview - 1 min ********************************* File systemsCS 372: Operating Systems Mike Dahlin 2 02/24/11 ********************************* Lecture - 20 min ********************************* 1. Scheduling problem definition Threads = concurrency abstraction Last several weeks: what threads are, how to build them, how to use them 3 main states: ready, running, waiting  Running: TCB on CPU  Waiting: TCB on a lock, semaphore, or condition variable queue  Ready: TCB on ready queue  Operating system can choose when to stop running one and when to start the next ready one. OS can choose which ready thread to start (ready “queue” doesn’t have to be FIFO) Key principle of OS design: separate mechanism from policy Mechanism – how to do something Policy – what to do, when to do itCS 372: Operating Systems Mike Dahlin 3 02/24/11 In this case, design our context switch mechanism and synchronization methodology allow OS to switch from any thread to any other one at any time (system will behave correctly) Thread/process scheduling policy decides when to switch in order to meet performance goals 1.1 Pre-emptive v. non-preemptive Non-preemptive – once a process starts, it is allowed to run until it finishes (or gives up CPU by calling “yield()” or wait())  simple and efficient to implement  creates problems (what are they? How to solve?) Pre-emptive – process switched between “ready” and “running” state  timer can cause context switch  more sophisticated and powerful  less efficient (more context switches) 2. Scheduling policy goals Step 1 in choosing a good policy is deciding on your goals: Today case study: balance 3 goals 1. Minimize response time – elapsed time to do an operation or job Response time is what user sees – elapsed time to • echo a keystroke in editor • compile a program • run a large scientific problem Response time = average (process end time – process start time) NOTE: THIS DEFINITION DIFFERS FROM THE ONE IN THE BOOK! 2. Maximize throughput - operations (or jobs) per second CPU utilization = time CPU is doing useful work/total elapsed time Two parts to max throughputCS 372: Operating Systems Mike Dahlin 4 02/24/11 a) minimize overhead context switch overhead – the time two switch between threads (handle interrupt, copy state, flush/reload caches, …) Note: b/c of context switch overhead, increasing frequency of context switches may reduce throughput b) efficient use of system resources (not only CPU, but also disk, memory, etc) 3. Fair – share CPU among users in some equitable way What does fairness mean? Fairness is interpreted in context of priorities -- if user says job A is more important than job B, is it fair to give job A more resources than B? (Yes.) Minimal definition of fairness: freedom from starvation Starvation – indefinite blocking Starvation free -- system guarantees that if a job j is ready, eventually it will run (regardless of workload/what new jobs arrive) Fairness v. minimize response time –fairness is sometimes a tradeoff against average response time. You can get sometimes get better average response time by making system less fair Note: 1) First step in evaluating policy is to pick goals 2) Goals can be in conflict (challenge in picking policy is evaluating trade-offs among goals for a workload) 3) Today look at 3 goals, but other goals exist: QUESTION: Other goals?  real timeCS 372: Operating Systems Mike Dahlin 5 02/24/11  predictable  … See vin’s notes, book for more details for policies evaluation of different algorithms under these goals. 3. Scheduling doesn't matter (usually) [at least not for response time, throughput. Ignore following for priority...] load v. response time curve (A little bit of queing theory) r = 1/(1-u) (exponential arrivals) --> When load low, scheduling doesn't matter When load high, scheduling doesn't matter When load medium, scheduling matters (but if load, hardware, application change, scheduling stops mattering) ... [also, for later discussion, when requests are small, equally important, and similar size, scheduling doesn't m atter] --> lots of servers do FIFO and are done... What does matter? 4. Overload control Servers often have highly variable load -- 4:1 typical -- flash crowd (e.g., UT emergency response server) -- ebay auction last few minutes -- ticketmaster -- high-profile event goes on sale...CS 372: Operating Systems Mike Dahlin 6 02/24/11 May be impossible (or frightfully expensive) to provision system to eliminate possiblity of overload overload often happens when service matters most! --> Must design servers to control overload Can't solve problem with scheduling. Solution 1: reduce work -- Distasteful answer, but sometimes necessary -- e.g., server with FIFO queue of work; make queue finite size Examples: -- reject requests (ugh, but simple) -- do less work per request -- e.g., switch from 720p to 480i video feed, serve static version of CNN front page rather than dynamically-generated (give up advertising revenue to survive crisis, slow down how frequenlty auction prices updated, ...) e.g., ebay http://www.cs.cornell.edu/courses/cs5410/2008fa/Slides/eBay.pdf -- Turn off other services -- e.g., mail server provides access to mailboxes, but queues outgoing and incoming mail NOTE: "Reduce work" can require careful design e.g., de facto way to limit load is to let network accept queue fill, but that is horrible for users e.g., stage 5 drops work when


View Full Document

UT CS 372 - Lecture 3 - CPU Scheduling

Documents in this Course
MapReduce

MapReduce

17 pages

Processes

Processes

19 pages

MapReduce

MapReduce

17 pages

Load more
Download Lecture 3 - CPU Scheduling
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Lecture 3 - CPU Scheduling and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Lecture 3 - CPU Scheduling 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?