Chapter Five -- CPU Scheduling -- Lecture Ideas

• What is a CPU burst? How are bursts distributed?
  
  
• What are preemptive and non-preemptive CPU scheduling?
  
  
  1. When process X switches from running to waiting (e.g. waiting for I/O, or a specified interval of time, or waiting for a signal from another process), X does not go to the ready queue. The short-term scheduler (a module of the OS) does not have the option to choose to dispatch X as the next process to run. (This is a case of NON-PREEMPTIVE scheduling)
     
     
  2. When process X switches from running to ready (e.g. when an interrupt from some I/O device forces X out of the CPU), the scheduler DOES have the option to dispatch X as the next user process to run, OR some other ready process. (This is a case where PREEMPTIVE scheduling can occur)
     
     
  3. When process X switches from waiting to ready (e.g. when one of its I/O's completes, or the signal it was wating for has arrived), the scheduler DOES have the option to dispatch X as the next user process to run, OR some other ready process. (This is a case where PREEMPTIVE scheduling can occur)
     
     
  4. When process X terminates, the scheduler does not have the option to choose to dispatch X as the next process to run. (This is a case of NON-PREEMPTIVE scheduling)
     
     
• A scheduling algorithm is preemptive if, in cases 2 or 3 above, it sometimes chooses NOT to continue running the current process -- the one that was running most recently.
  
  
• Fact: While the OS is in the act of changing shared data there has to be a mechanism that prevents other processes from getting access to the data. *Part* of the mechanism may be a scheduler policy not to preempt such "critical sections" of OS code.
  
  
• What is the job of the dispatcher module of an operating system?
  
  
• Discuss 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
    
    
• What are these scheduling methods and what are some of their advantages and disadvantages? What class(es) of process do they favor?
  
  
  • FCFS -- easily understood and implemented -- non-preemptive -- can lead to long average waiting times -- is subject to the "convoy effect."
    
    
  • SJF -- difficult to implement perfectly -- usually requires time estimates -- pure SJF gives minimum average wating 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 when there is no one there with a more urgent need. Even after all the people who were there when you arrived are served, it doesn't mean you must be served next because more people could have arrived in the meantime with more urgent need than you. There is no limit on the number of people who will be served before you are served. You will probably be served eventually, but 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
    
    
• Discuss Multilevel Queue Scheduling -- different kinds of jobs at different priority levels -- a queue at each level with its own particular scheduling algorithm. "Scheduling among the queues" might be done on a priority or time-slicing basis.
  
  
• Discuss Multilevel Feedback Queue Scheduling -- flexible but complex -- a process can move from one queue to another. BSD unix used a multilevel feedback queue arrangement.
  
  
• Discuss Multiple-Processor Scheduling
  
  
  • per-processor ready queues versus single ready queue -- there is an issue of load-balancing
    
    
  • single scheduler versus shared ready queue -- the simple approach may not scale well.
    
    
• Discuss real-time scheduling -- hard and soft
  
  
  • Hard real-time scheduling requires that we employ a special real-time operating system.
    
    
  • Soft real-time scheduling
    
    
    • Give the real-time process the highest priority throughout its lifetime.
      
      
    • Make sure the system has a small dispatch latency
      
      
      • One way is to make system calls interruptible at "safe" preemption points
        
        
      • A more radical and potentially effective approach is to make the entire kernel preemptible using critical section synchronization methods (e.g. semaphores).
        
        
      • priority inversion problem and priority-inheritance solution. (If a low priority process L is accessing a resource R needed by a high priority process H, and it is not practical to preempt R from L, then we may temporarily raise the priority of L to the priority of H so that L will get finished with R quickly and H can get R.)
        
        
• Evaluation/selection of scheduling algorithm
  
  
  • describe and prioritize performance goals that are affected by scheduling, such as response time and throughput.
    
    
  • Evaluate using 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 Queueing Models
    
    
    • prepare by gathering system statistics
      
      
      • distribution of CPU and I/O bursts
        
        
      • distribution of job arrival-time
        
        
    • do queueing 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 correlations 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 behaviour 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.
      
      
• Solaris2 Scheduling
  
  
  • priority scheduling -- four priority levels: real time, system, time-sharing, interactive
    
    
  • time sharing processes use a multilevel feedback queue
    
    
  • generally low priority processes get a larger time slice, and
    
    
  • higher priority processes get a smaller time slice
    
    
• Windows 2000 Scheduling
  
  
  • priority based and preemptive
    
    
  • variable class with priorities 1 to 15
    
    
  • real-time class with priorities from 16 to 31
    
    
  • memory management has priority 0
    
    
  • priorities of threads in the variable class can change
    
    
  • if a thread in the variable class uses up its time quantum, its priority is lowered, but never below a certain base value
    
    
  • The dispatcher boosts the priority of a thread in the variable class when it is released from a wait queue
    
    
  • foreground processes that a user is interacting with have 3 times larger quantum than "background processes."
    
    
• Linux scheduling
  
  
  • Linux has a time-sharing scheduling algorithm and a real-time scheduling algorithm
    
    
  • time-sharing algorithm uses a credit system -- constantly running processes tend to lose credits and processes that spend a lot of time waiting tend to gain credits.