(Latest Revision:
October 20, 2014 (DRAFT ONLY)
)
Chapter Five -- CPU Scheduling -- [[DRAFT]] Lecture Notes
- 6.0 Objectives
- Introduce CPU scheduling
- describe scheduling algorithms
- learn criteria for evaluating scheduling algorithms
- 6.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
- 6.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
- 6.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 -- can't be implemented perfectly at the level of
short-term scheduling -- instead the scheduler employs an estimate
of the length of the next burst -- 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 -- aging is the elevation of the priority
of processes that have not received CPU time -- 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 similar to what happens if you go to the
emergency room with a sore throat. 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
who need care more urgently than you. There is no limit to 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 and 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.
This algorithm might implement strict priorities among the queues,
or time-slice among them.
- 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.
- 6.4 Thread Scheduling
- 6.5 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'.
- Processor affinity can be soft or hard.
- Another factor is architectures with non-uniform memory access
(NUMA) -- e.g. when there are multiple integrated CPU and memory
units. Here it is advantageous for scheule and memory allocator to
keep processes running on CPU's close to the process memory.
- 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.
- Multicore processors are basically multiprocessors on a single chip.
- A cores may implement two or more logical processors by supporting
the compute cycle of one thread during the memory stall cycle(s) of
the other(s).
- This means that one level of scheduling is done by the hardware of
the cores when they select among the threads assigned to them.
- Things like time-slicing tend to be difficult to get right on a
virtual machine. Let's say there is a set of instructions that
should run in about a tenth of a second on real hardware. Those
same instructions may take much longer on a virtual machine running
on a host system that is busy with other work.
- 6.6 Operating System Examples
- Solaris 9 has six scheduling classes: Time sharing, Interactive,
Real time, System, Fair share, and Fixed priority.
- 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.
- In essence the scheduling algorithm is a table-driven and preemptive
priority system.
- 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. Windows also typically triples the quantum of such a
process.
- The Linux system has a modernized scheduler. It makes its decision
in O(1) time and supports processor affinity and load balancing.
- The Linux scheduler is preemptive and priority based.
- Linux gives high priority processes a longer quantum - unlike
Solaris and Windows XP.
- 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.
- 6.7 (Scheduling) Algorithm Evaluation
How do we select CPU scheduling algorithms?
First we must choose the goals we want the scheduling algorithm to
achieve, such as response time of less than one second, or low variance
in wait time.
Next we need ways to evaluate algorithms to see if they will achieve the
chosen goals.
- Deterministic modeling -- calculate performance based on
specific test inputs -- this can be effective when trying to find an
good 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 queue lengths and waiting times
- 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
- trace tapes have the advantage of making it possible to compare
different algorithms on the exact same inputs.
- 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 scheduling
algorithms on an actual system and measure their performance
- there are high costs of coding and system modification
- inconvenient to users may be considerable
- 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.