CS162 Operating Systems and Systems Programming Lecture 11 Thread Scheduling (con’t) Protection: Address SpacesReview: Banker’s Algorithm for Preventing DeadlockReview: Last TimeReview: FCFS and RR Example with Different QuantumReview: SRTF Further discussionGoals for TodayExample to illustrate benefits of SRTFSRTF Example continued:Predicting the Length of the Next CPU BurstMulti-Level Feedback SchedulingScheduling DetailsAdministriviaScheduling FairnessLottery SchedulingLottery Scheduling ExampleHow to Evaluate a Scheduling algorithm?A Final Word On SchedulingVirtualizing ResourcesRecall: Single and Multithreaded ProcessesImportant Aspects of Memory MultiplexingBinding of Instructions and Data to MemoryMulti-step Processing of a Program for ExecutionRecall: UniprogrammingMultiprogramming (First Version)Multiprogramming (Version with Protection)Segmentation with Base and Limit registersIssues with simple segmentation methodMultiprogramming (Translation and Protection version 2)Example of General Address TranslationTwo Views of MemoryExample of Translation Table FormatDual-Mode OperationFor Protection, Lock User-Programs in AsylumHow to get from KernelUserUserKernel (System Call)System Call ContinuedUserKernel (Exceptions: Traps and Interrupts)Additions to MIPS ISA to support Exceptions?Intel x86 Special RegistersCommunicationClosing thought: Protection without HardwareSummarySummary (2)CS162Operating Systems andSystems ProgrammingLecture 11Thread Scheduling (con’t)Protection: Address SpacesOctober 5, 2009Prof. John Kubiatowiczhttp://inst.eecs.berkeley.edu/~cs162Lec 11.210/5/09 Kubiatowicz CS162 ©UCB Fall 2009•Banker’s algorithm:–Allocate resources dynamically»Evaluate each request and grant if some ordering of threads is still deadlock free afterward »Technique: pretend each request is granted, then run deadlock detection algorithm, substituting ([Maxnode]-[Allocnode] ≤ [Avail]) for ([Requestnode] ≤ [Avail])Grant request if result is deadlock free (conservative!)»Keeps system in a “SAFE” state, i.e. there exists a sequence {T1, T2, … Tn} with T1 requesting all remaining resources, finishing, then T2 requesting all remaining resources, etc..–Algorithm allows the sum of maximum resource needs of all current threads to be greater than total resourcesReview: Banker’s Algorithm for Preventing DeadlockLec 11.310/5/09 Kubiatowicz CS162 ©UCB Fall 2009Review: Last Time•Scheduling: selecting a waiting process from the ready queue and allocating the CPU to it•FCFS Scheduling:–Run threads to completion in order of submission–Pros: Simple (+)–Cons: Short jobs get stuck behind long ones (-)•Round-Robin Scheduling: –Give each thread a small amount of CPU time when it executes; cycle between all ready threads–Pros: Better for short jobs (+)–Cons: Poor when jobs are same length (-)Lec 11.410/5/09 Kubiatowicz CS162 ©UCB Fall 2009 QuantumCompletionTimeWaitTimeAverageP4P3P2P1Review: FCFS and RR Example with Different QuantumP2[8]P4[24]P1[53]P3[68]0 8 32 85 153Best FCFS:6257852284Q = 1104½11215328125Q = 20100½8115330137Q = 166¼ 88852072Q = 2031¼885032Best FCFS121¾14568153121Worst FCFS69½32153885Best FCFS83½121014568Worst FCFS95½8015316133Q = 857¼5685880Q = 899½9215318135Q = 1099½8215328135Q = 561¼68851082Q = 1061¼58852082Q = 5Lec 11.510/5/09 Kubiatowicz CS162 ©UCB Fall 2009Review: SRTF Further discussion•Starvation–SRTF can lead to starvation if many small jobs!–Large jobs never get to run•Somehow need to predict future–How can we do this? –Some systems ask the user»When you submit a job, have to say how long it will take»To stop cheating, system kills job if takes too long–But: Even non-malicious users have trouble predicting runtime of their jobs•Bottom line, can’t really know how long job will take–However, can use SRTF as a yardstick for measuring other policies–Optimal, so can’t do any better•SRTF Pros & Cons–Optimal (average response time) (+)–Hard to predict future (-)–Unfair (-)Lec 11.610/5/09 Kubiatowicz CS162 ©UCB Fall 2009Goals for Today•Finish discussion of Scheduling•Kernel vs User Mode•What is an Address Space?•How is it Implemented?Note: Some slides and/or pictures in the following areadapted from slides ©2005 Silberschatz, Galvin, and GagneLec 11.710/5/09 Kubiatowicz CS162 ©UCB Fall 2009Example to illustrate benefits of SRTF•Three jobs:–A,B: both CPU bound, run for weekC: I/O bound, loop 1ms CPU, 9ms disk I/O–If only one at a time, C uses 90% of the disk, A or B could use 100% of the CPU•With FIFO:–Once A or B get in, keep CPU for two weeks•What about RR or SRTF?–Easier to see with a timelineCC’s I/OC’s I/OC’s I/OA or BLec 11.810/5/09 Kubiatowicz CS162 ©UCB Fall 2009SRTF Example continued:C’s I/OCABAB… CC’s I/ORR 1ms time sliceC’s I/OC’s I/OCA BCRR 100ms time sliceC’s I/OACC’s I/OAASRTFDisk Utilization:~90% but lots of wakeups!Disk Utilization:90%Disk Utilization:9/201 ~ 4.5%Lec 11.910/5/09 Kubiatowicz CS162 ©UCB Fall 2009Predicting the Length of the Next CPU Burst•Adaptive: Changing policy based on past behavior–CPU scheduling, in virtual memory, in file systems, etc–Works because programs have predictable behavior»If program was I/O bound in past, likely in future»If computer behavior were random, wouldn’t help•Example: SRTF with estimated burst length–Use an estimator function on previous bursts: Let tn-1, tn-2, tn-3, etc. be previous CPU burst lengths. Estimate next burst n = f(tn-1, tn-2, tn-3, …)–Function f could be one of many different time series estimation schemes (Kalman filters, etc)–For instance, exponential averagingn = tn-1+(1-)n-1with (0<1)Lec 11.1010/5/09 Kubiatowicz CS162 ©UCB Fall 2009Multi-Level Feedback Scheduling•Another method for exploiting past behavior–First used in CTSS–Multiple queues, each with different priority»Higher priority queues often considered “foreground” tasks–Each queue has its own scheduling algorithm»e.g. foreground – RR, background – FCFS»Sometimes multiple RR priorities with quantum increasing exponentially (highest:1ms, next:2ms, next: 4ms, etc)•Adjust each job’s priority as follows (details vary)–Job starts in highest priority queue–If timeout expires, drop one level–If timeout doesn’t expire, push up one level (or to top)Long-Running ComputeTasks Demoted to Low PriorityLec 11.1110/5/09 Kubiatowicz CS162 ©UCB
View Full Document
Unlocking...