Chapter Five -- CPU Scheduling -- Lecture Notes

• 5.0 Objectives
  • Introduce CPU scheduling
  • describe scheduling algorithms
  • learn criteria for evaluating scheduling algorithms
  
  
• 5.1 Basic Concepts
  
  
  • Graphs of process burst frequency versus duration tend to be (hyper)exponential - lots of short bursts and very few long ones.
    
    
  • The job of the short-term scheduler of the OS is to choose the next job from the ready queue to be allowed to run in the CPU. The actual data structure in the ready queue is usually a process control block (PCB).
    
    
  • Sometimes the current process, P, in the CPU is removed from the CPU by an interrupt or trap but it remains ready to run and goes immediately back into the ready queue. If, under those circumstances, the short-term scheduler decides to run a process other than P next, then we say P has been preempted. A scheduler capable of preempting is called a preemptive scheduler.
    
    
  • A system with a preemptive short-term scheduler will be much more responsive in some situations. This is very desirable. However, it tends to be a challenge to protect shared data structures from corruption in such systems.
    
    
  • The dispatcher is the part of the OS that actually puts a process in the CPU. The dispatcher performs the data movement associated with context switching, switches to user mode, and jumps to the requisite instruction within the user process. The work done by the dispatcher is typically a system bottleneck, and so it is very important that it run as fast as possible. The time it requires is called the dispatch latency
  
  
• 5.2 Scheduling Criteria
  
  
  • Goals of short-term scheduling: high CPU utilization: high throughput, short turnaround time, short waiting time, short response time.
    
    
  • throughput == jobs completed per unit time
    
    
  • turnaround == time from submission to completion
    
    
  • wait time == time spent in the ready queue
    
    
  • response time == time from submission to start of first response
  
  
• 5.3 Scheduling Algorithms
  
  
  • FCFS -- easily understood and implemented -- non-preemptive -- can lead to long average waiting times -- is subject to the "convoy effect" wherein either the CPU or I/O channel is not in use because all the I/O-bound are stuck 'behind' a CPU-bound process.
    
    
  • SJF -- difficult to implement perfectly -- usually requires time estimates -- pure SJF gives minimum average waiting time -- can be preemptive or non-preemptive -- if preemptive then when a shorter job enters the queue, the running job must be replaced with the new job ASAP.
    
    
  • HPJF -- can be preemptive or non-preemptive -- can lead to starvation (SJF is a form of HPJF) -- aging used in conjunction with HPJF can avert starvation -- Unix is interesting in that "priority" is actually based on "starvation" so low priority processes don't starve simply because starvation causes the priority to become higher.
    
    
  • Starvation: (a.k.a. indefinite postponement) This phenomenon is like what happens when you go to the emergency room with a hangnail. You will be served if and when there is no one there with a more urgent need. After all the people who were there when you arrived are served, you may still have to wait longer because more people could have arrived in the meantime with needs that are more than yours. There is no limit on the number of people who will be served before you are served. You will probably be served eventually, but even that is not certain.
    
    
  • RR -- designed for time-sharing -- circular queue and time-slicing (quantizing) -- preemptive -- response times tend to be short -- average wait times tend to be high -- there tends to be a high amount of context-switching overhead -- to avoid excessive overhead we need the quantum to be large in comparison with the context-switch time -- to get low turnaround times the quantum should be larger than the average CPU burst time -- on the other hand the quantum has to be small enough to produce good response time.
    
    
  • Multilevel Queue Scheduling -- You can divide processes into several different types have a separate ready-queue for each type (e.g. foreground processes, background, system, interactive editing, ...) You can have a different scheduling algorithm for each queue - tailored to that type of process. You also need to design an algorithm that decides which queue to service, and when.
    
    
  • Multilevel Feedback Queue Scheduling -- Put jobs in queues based on recent CPU usage. Allow migration from queue to queue. 'Hungrier processes' move up to higher priority queues - prevents starvation.
  
  
• 5.4 Multiple-Processor Scheduling
  
  
  • Asymmetric Multiprocessing (AMP) is a possibility: All OS code runs on just one processor & so only one process at a time has access to system data structures.
    
    
  • Virtually all modern OS's support Symmetric Multiprocessing (SMP) - system code can run on any processor, OS code on each processor schedules that processor.
    
    
  • SMP can be used in conjunction with either a common ready queue or separate ready queues for each process.
    
    
  • Access to a common ready queue has to be programmed carefully.
    
    
  • On the other hand, load balancing can be problematic if there is a separate ready queue for each processor.
    
    
  • Processor Affinity If a process migrates from one processor to another, the old instruction and address caches become invalid and caches on the new processor have to become 'populated'.
    
    
  • Push migration is an approach to load balancing - a system process periodically checks ready queues and moves processes if need be.
    
    
  • Pull migration - another approach - OS code running on a processor with little to do takes jobs from other ready queues.
    
    
  • Note that push/pull migration tends to work counter to the idea of processor affinity.
  
  
• 5.5 Thread Scheduling
  
  
  
  
• 5.6 Operating System Examples
  
  
  • Solaris has four scheduling classes: real time, system, time sharing, and interactive.
    
    
  • The solaris time-sharing class schedule model is a multi-level feedback queue. High priority is given to processes that have used little CPU time lately. The lower priority processes are given larger timeslices.
    
    
  • Processes in the real-time class have priority higher than any other class.
    
    
  • Solaris 9 added two more scheduling classes.
    
    
  • Windows XP also has a real-time class with highest priority. (This is 'fudged' slightly because the memory manager has precedence even over real-time processes.)
    
    
  • There is a queue for each priority & the scheduler works off the highest-priority non-empty queue.
    
    
  • Real-time priorities are immutable but others can change.
    
    
  • Typically the priority is lowered if the quantum expires.
    
    
  • As with Solaris, and most unix's, the priority is boosted when the process returns from a wait.
    
    
  • Both Windows and Solaris give the active window process a priority boost.
    
    
  • The Linux system has a modernized scheduler. It makes its decision in O(1) time and supports processor affinity and load balancing.
    
    
  • Linux gives high priority processes a longer quantum and vice-versa.
    
    
  • A process that has used its time slice has to stop running until all the other processes use up theirs.
    
    
  • Linux gives higher priority to processes returning from long waits.
  
  
• 5.7 (Scheduling) Algorithm Evaluation
  
  
  • Deterministic modeling -- calculate performance based on specific test inputs -- this can be effective when trying to find an effective scheduling technique for a system that tends to run the same kind of program over and over, often with very similar input from run to run -- e.g. payroll processing, census calculations, and weather prediction. This is not the style of most personal computer users, but it is nevertheless not uncommon in business and government.
    
    
  • Evaluate using Queuing Models
    
    
    • prepare by gathering system statistics
      • distribution of CPU and I/O bursts
      • distribution of job arrival-time
      
      
    • do queuing network analysis -- get figures for things like average waiting time
      
      
    • the mathematics can be difficult so often researchers make simplifying assumptions
      
      
    • Naturally the results may be "weaker" because of the simplifying assumptions.
      
      
  • Evaluate using Simulations
    
    
    • represent major components and activities of the system with software functions and data structures.
      
      
    • use a variable to represent a clock and update system state variables after each "tick"
      
      
    • measure desired characteristics of the (simulation of the) system
      
      
    • use random numbers and assumed distributions to produce inputs to the system, or use traces from actual running systems
      
      
    • random numbers and assumed distributions may not capture enough information such as correlation in time between different kinds of events.
      
      
    • traces can take up a lot of space on secondary storage
      
      
    • simulations can be expensive to code and require long periods of time to run
      
      
  • Evaluation by Implementation -- implement a scheduling algorithm on an actual system and measure its performance
    
    
    • cost of coding
      
      
    • may be inconvenient to the users
      
      
    • user behavior may change in response to new scheduling algorithm so the benefits of the algorithm may not persist
      
      
    • it may be useful to allow managers and users to "tune" the scheduling policy of the running system. Not many of today's operating systems are tunable.
      
      
    • Some versions of unix can be tuned - Solaris has a dispadmin command for changing parameters of schedule classes.