Chapter 5.1: CPU Scheduling

1
Chapter 5.1 CPU Scheduling
2
Chapter 5 CPU Scheduling

• Chapter 5.1
• Basic Concepts
• Scheduling Criteria
• Scheduling Algorithms
• Chapter 5.2
• Multiple-Processor Scheduling
• Real-Time Scheduling
• Thread Scheduling
• Operating Systems Examples
• Java Thread Scheduling
• Algorithm Evaluation

3
Basic Concepts

• The goal of multiprogramming is to maximize CPU
  utilization - constrained by other needs too.
• So, we speak of CPU schedulingWe want to keep
  that CPU computing! How do we keep this
  expensive resource chugging!
• This means we look at the way the CPU is
  dispatched to processes.
• Equivalently, then, we need to look at the
  scheduling algorithms.
• We will speak of process scheduling in discussing
  general issues and thread scheduling when we
  speak of issues directly related to threads only.
• We know that in a single processor system, only a
  single process can execute at any instant in
  time
• That is, a single instruction from a single
  process can execute at any instant in time.
• When the CPU must wait for some other event, it
  is idle.
• In most instances (there are exceptions), this
  practice is to be avoided!
• We want to keep this resource busy rather than
  let it set idle!

4
Basic Concepts

• Normally a process continues executing until it
  issues a system call like for a read or write,
  or the process is interrupted for maybe the timer
  or other reason by the operating system.
• Once a system call is issued, we normally do NOT
  want the processor to wait for system call
  completion.
• Rather than have the CPU wait, we want to
  dispatch the CPU to another ready process.
• This switching of context - is central to the
  smooth running of a computing environment!

5
CPU and I/O Bursts

• Reality is that many processes have repeating
  cycles of what are called cpu bursts where
  computing is taking place, followed by I/O
  bursts where an I/O operation occurs.
• Typically, CPU bursts are very short-lived (since
  computers process so quickly) while an I/O
  request is made.
• CPU-bound processes may have a few long CPU
  bursts with less frequent I/O bursts, while an
  I/O bound process may have many short
  CPU-bursts but a much higher number of I/O
  bursts.

6
Histogram of CPU-burst Times
Longer and more frequent CPU bursts characterize
scientific, engineering applications where
shorter CPU bursts and much more frequent I/O
bursts characterize business and commercial
applications. Relate to file / database
processing vis a vis computationally-intense
processing.
7
CPU Scheduler (short-term scheduler)

• This scheduler selects from among processes in
  memory ready to execute, and allocates the CPU to
  one of them.
• Ready means that these processes can use the
  CPU immediately! They are not waiting on an I/O
  or a keyboard input or some kind of transmission!
• Selection is not necessarily accessing a FIFO
  queue, as there are a number of scheduling
  algorithms (fifo, priority, tree, unordered
  linked list, and more)
• These queues consist of the PCBs representing
  processes.
• These PCBs are linked up in various ways links,
  ordered array, etc. as we shall see.
• CPU scheduling decisions may take place when a
  process
• 1. Switches from running to waiting state (like
  after process or thread issues a system call)
• 2. Switches from running to ready state (like
  after a timer interrupt or other interrupt)
• 3. Switches from waiting to ready state (like
  when an I/O is completed process is made
  ready to resume)
• A Process terminates
• Now lets look at how this scheduling takes
  place

8
Preemptive / Non-preemptive Scheduling

• Changing from running state to wait state
  non-preemptive
• Often occurs due to an I/O request from the
  running process, or
• Invocation of a wait for termination of a child
  process (threads)
• Process currently undergoing execution is not
  interrupted (preempted)!
• Changing state from running to ready state
  preemptive
• May occur as a result of an interrupt.
• Running process is cut off and moves from
  running to ready.
• Changing state from wait state to a ready state
  preemptive
• May occur once an I/O has been completed
• Process in wait state may now be rescheduled
  (thus moved to ready state.
• Changing state because process terminates
  non-preemptive.
• This is clear.

9
Preemptive / Non-Premptive Scheduling - more

• In non-preemptive scheduling, once a process
  receives the CPU, this process / thread continues
  until it releases the CPU (I/O, switch to wait,
  timer, terminates) It cannot be bumped.
• Most newer operating systems use preemptive
  scheduling.
• Preemptive scheduling requires additional
  hardware a timer that keeps track of how long a
  process receives CPU cycles.
• So, non-preemptive (cooperative) scheduling can
  be used on all hardware configuration whereas
  preemptive scheduling requires a timer.

10
Problems in Preemptive Scheduling

• Problems here mainly center around sharing data.
• If a process is interrupted and is currently
  updating data and another process is given
  control who needs to access this data, we have
  problems.
• This situation is quite real and is addressed in
  the next chapter where we talk about process
  synchronization.
• At the kernel level, preemptive scheduling can be
  disastrous!
• Kernel may be involved with system routines
  such as organizing a queue
• System Calls In some systems (Unix is one),
  some system calls or an I/O block may be allowed
  to take place before preemption. (eliminates
  potential inconsistent internal data structures,
  etc.)
• Interrupts. But some interrupts can occur
  anytime and some types of interrupts simply
  canNOT be ignored by the kernel.
• In these cases, certain interrupts may be
  temporarily disabled (sometimes called masked)
  and re-enabled later via priority interrupts.
  More in later sections

11
Dispatcher

• Dispatcher module gives control of the CPU to the
  process selected by what your author calls the
  short-term scheduler this involves
• switching context (much work done here)
• Lots more coming on this one
• Dispatch latency refers to the time it takes
  for the dispatcher to stop one process and start
  another.
• The amount of time spent in context switching can
  be very significant, especially if done a great
  deal (which it is!)

12
Scheduling Criteria - Metrics

• Goal of CPU utilization Keep CPU as busy as
  possible!!
• Books says range from 40 lightly-loaded to 100
  heavily loaded are desirable. But this depends
  on a lot of parameters and the nature of the
  computing enviornment
• Throughput Number of processes completed per
  time unit
• Can vary due to nature of processes (many short
  processes ? lots of throughput few long
  processes ? low throughput)
• Here again, are the processes CPU-bound or I/O
  bound processes? Mixture?
• Turnaround time total span time to execute a
  particular process (wait, queue time, executing
  )
• Waiting time total time process spends in ready
  queue
• Response time amount of time it takes from when
  a request was submitted until the first response
  is produced, not output (for time-sharing
  environment)

13
Optimization Criteria

• AS stated, a goal is to maximize CPU utilization
  and throughput and minimize turnaround time,
  wait, and response time..
• In some environments, some of these metrics are
  more important than others.
• Normally, what we concentrate on are averages.
• ? Sometimes more desirable to optimize certain
  values at expense of others again, depending on
  the computing environment.
• E.g. In interactive systems, probably best to
  minimize the variance rather than minimize the
  average response time.
• The entire area can be quite involved and very
  complicated.
• Lets turn our attention to some scheduling
  algorithms

14
First-Come, First-Served (FCFS) Scheduling
CPU scheduling easily managed with a FIFO
queue. New process is linked to tail of
queue. CPU is allocated to process at head of
queue Code is easy to write. Note data to the
right. AVERAGE wait time is high due to
these arrival rates 17 msec here!

• Process Burst Time
• P1 24
• P2 3
• P3 3
• Suppose that the processes arrive in the order
  P1 , P2 , P3 The Gantt Chart for the schedule
  is
• Waiting time for P1 0 P2 24 P3 27
• Average waiting time (0 24 27)/3 17
• Given these processes, average wait time is
  somewhat
• long

15
FCFS Scheduling (Cont.)

• Suppose that the processes arrive in the order
• P2 , P3 , P1
• The Gantt chart for the schedule is
• Waiting time for P1 6 P2 0 P3 3
• ? Average waiting time (6 0 3)/3 3
• Much better than previous case
• Convoy effect short process behind long process
• Very troublesome for time-sharing systems where
  users need to share CPU regularly.
• Non-preemptive. CPU process holds CPU

Note if the arrivals arrive in a different
order, average wait time is much less!! Point
average wait time under an FCFS policy is
generally not minimal. Can vary greatly! But now
consider if we have one CPU bound process and
several I/O bound processes CPU-bound process
will get and hold CPU while all the I/Os are
completed (these I/O devices will become
idle) I/O bound processes will then have very
short CPU bursts (CPU-process is ready) and
the I/O bound processes move back to I/O
queues. Result is in very low CPU and device
utilization. Perhaps better results if shorter
processes were allowed to go first.
16
Shortest-Job-First (SJF) Scheduling

• Associate with each process the length of its
  next CPU burst.
• Use these lengths to schedule the process with
  the next shortest CPU burst time. This way, the
  CPU is better utilized and I/O processes dont
  have to wait too long for the CPU
• Two schemes
• nonpreemptive once CPU given to the process it
  cannot be preempted until completes its CPU burst
• preemptive if a new process arrives with CPU
  burst length less than remaining time of current
  executing process, preempt the currently running
  process!
• This scheme is know as the Shortest-Remaining-Time
  -First (SRTF)
• SJF is optimal ? minimum average waiting time for
  a set of processes
• This approach moves a newly arriving process
  ahead of a long one which may already be in the
  ready queue.
• Problem how do you determine the length of the
  next CPU request?
• Ahead, first lets look at preemptive and
  non-preemptive SJF scheduling

17
Example of Non-Preemptive SJF

• Process Arrival Time Burst Time
• P1 0.0 7
• P2 2.0 4
• P3 4.0 1
• P4 5.0 4
• SJF (non-preemptive)
• Average waiting time (0 6 3 7)/4 4

• Discuss
• Non-preemptive
• Job running is
• not switched.
• Next job subscribes
• to the algorithm
• Go through this

All arrive during P1 running
Note P1 finishes before next process is given
to the CPU. Not preempted.
18
Example of Preemptive SJF
Note the preemptive scheduling P2 arrives
requiring burst of four while P1 still requires
5msec. This causes P1 to be queued P2 starts
(requires 4 msec), but P3 arrives (needing
1msec) P2 still needs 2msec. P2 is
preempted. P3 concludes, leaving P2 with 2 msec
needed yet. P2 is resumed. Then P4 is runs to
end P1 finishes

• Process Arrival Time Burst Time
• P1 0.0 7
• P2 2.0 4
• P3 4.0 1
• P4 5.0 4
• SJF (preemptive)
• Average waiting time (9 1 0 2)/4 3

19
Determining Length of Next CPU Burst

• I will skip all the math involved exponential
  averaging, which takes into account recent and
  past information on bursts.
• But this algorithm must be implemented and run in
  order to determine the length of the next CPU
  burst (anticipated).

20
Priority Scheduling

• A priority number (integer) is typically
  associated with a process
• The CPU is allocated to the process with the
  highest priority (almost always smallest
  integer ? highest priority)
• (SJF was simply a priority scheduling where
  priority is the predicted next CPU burst time)
• Clearly this favors short CPU-bound jobs!! Not
  too good for I/O bound jobs!!
• But Priority Scheduling in general, has many
  parameters.
• Note that high and low priorities have a
  range of numbers maybe 0 4095.
• No general agreement as to whether low numbers
  are high priority or vice versa! Ha. We will
  assume low numbers are high priority processes.
• Priorities can be determined by many factors
• Internal metrics might include time limits,
  memory requirements, numbers of open files, ratio
  of average I/O burst to over CPU burst and more
• There may well be external metrics set by
  criteria outside operating system importance of
  the process, type / amount of funds paying for
  computer use, department sponsoring work, maybe
  political factors, and more.

21
Priority Scheduling - More

• And,to complicate things, priority scheduling may
  be both preemptive and non-preemptive.
• Typically a newly arriving processes ? the Ready
  Queue.
• If our scheduling is preemptive and if priority
  of the new process is gt that of running process,
  this currently running process is preempted
• if priority scheduling is non-preemptive,
  priority is calculated and, if it has highest
  priority, this new process may be put at the
  head of the Ready Queue executing process
  continues.
• Problems
• Problem ? Starvation (indefinite blocking) low
  priority processes may never execute
• In heavily loaded system, low-priority processes
  may never get the CPU!
• Process eventually runs or computer system
  crashes and all unfinished low-priority processes
  are lost.
• Solution ? Aging as time progresses increase
  priority of the process
• Some internal algorithm increases priority per
  unit time interval.
• Book cites range of 127 to 0 (0 is high
  priority). Waiting process priority is bumped
  by one every fifteen minutes.
• Eventually this process will get run
• In this scheme, if a process was priority 127, it
  would take no longer than 32 hours for this
  process to age to a priority 0 process!
• History abounds of horror stories encountered via
  Starvation. A funny read!!

22
Round Robin (RR)

• This algorithm is designed especially for
  time-sharing systems so all users get good
  response times.
• Each process allocated a small unit of CPU time
  (time quantum), usually 10-100 milliseconds.
• After time has elapsed, the process is preempted
  and added to end of the ready queue.
• Ready queue is implemented as a circular queue.
• New processes added to tail of queue removed
  from queue head.
• Standard queuing algorithms.
• Timer is set to interrupt after one quantum
  however this quantum is determined...
• If process has a CPU burst of lt one time quantum,
  process releases the CPU.
• Usually this is the result of a system call.
• If process runs gt one time quantum, timer causes
  an interrupt.
• Context switching takes place, process is put at
  tail of ready queue
• CPU scheduler takes next process typically at the
  head of ready queue in the round robin approach.

23
Round Robin Process Scheduling - more

• So is performance improved this way?
• And what is the length of the time quantum?
• Is this a one size fits all?
• Average performance can be slow if we average a
  process requiring several quanta with processes
  that have CPU bursts lt one quantum.
• In this case, no one process is allocated more
  time than one quantum (and we may have a slow
  average turnaround)
• We know that the Round Robin scheduling algorithm
  is preremptive.
• Consider an example with the quantum 20 msec

24
Example of RR with Time Quantum 20 msec

• Process Burst Time
• P1 53
• P2 17
• P3 68
• P4 24
• The Gantt chart is
• Discuss remaining CPU time necessary after each
  burst.
• Issues
• If time quantum is large, the round robin is
  about the same as FCFS policy (non-preemptive
  too)
• If time quantum is small (like 1 msec), RR is
  called processor sharing and creates the illusion
  that each process has its own processor.
• But the overhead of context switching is
  horrible!

What the processes need Note they arrive in
this order too.
What they get with 20 msec quanta
25
Time Quantum and Context Switch Time
Another factor it does take time to switch
context. So if q is very small, there will be a
disproportionate number of switches and this
requires a good deal of overhead. Need quantum
to be large enough so that the overhead of
context switching is not terribly
significant. Most modern systems have time quanta
from 10-100 msec with a typical context
switching time of 10 microseconds. So, context
switching here is a very small percentage of a
time quantum 1/1000 of the smallest of these
quanta (10 msec)!
Look at this visual. I will not discuss in
class.
26
Time Quantum and Turnaround Time - Varies

• Clearly turnaround time depend on the size of
  the quantum and the characteristics of the
  computing mix!
• While there are no clear cut solutions, in
  general the average turnaround time can be
  improved if most processes finish their next CPU
  burst in a single time quantum.
• This means they will release the CPU a bit early
  and would not be moved to a Ready Queue -
  probably
• In general, the time quantum should be
  compared to the overhead of context switching.
• In general terms, we have a rule of thumb
  (heuristic) 80 of the CPU bursts should be
  shorter than the time quantum.

27
Multilevel Queue

• Sometimes the Ready Queue is partitioned into
  separate queues
• A foreground queue for interactive processes, and
  
• A background queue for batch processing.
• These types of processes have difference
  requirements and hence very different scheduling
  needs.
• Discuss.
• Within each of these queues is its own scheduling
  algorithm
• foreground RR and this makes sense for
  interactive processing where everyone needs to
  feel they are getting the CPU very often if not
  constantly!
• background FCFS good for standard operations
  fair.
• Typically processes are assigned to a specific
  queue depending on a number of process
  characteristics (memory requirements, CPU needs,
  I/O needs, etc.)
• A lot of these parameters can be determined up
  front.

28
Multilevel Queue Scheduling
We said that scheduling must be done among
the queues. Two primary options Fixed priority
preemptive scheduling (i.e., serve all jobs from
foreground - then from background).
Possibility of starvation especially for batch or
student jobs!! Time slice each queue gets a
certain amount of CPU time which it can schedule
amongst its processes i.e., 80 to
foreground in RR 20 to background in FCFS
Discuss. PUFFT
29
Multilevel Feedback Queue

• Using feedback, this scheduling algorithm allows
  a process to move between the various queues
  very nice way to implement aging.
• Processes can be reallocated to queues
  dynamically
• Process using too much CPU time can be moved to a
  lower priority queue.
• The leaves I/O bound processes interactive
  processes in the higher priority queues. (Why
  might this be good???)
• A process that spends a long time in a lower
  priority queue may be moved up.
• Characteristics of this multi-level feedback
  queue scheduler
• There are a number of queues
• There are scheduling algorithms for each queue
• There are methods used to determine when to
  upgrade a process
• And methods used to determine when to demote a
  process
• And methods used to determine which queue a
  process will enter when that process needs service

30
Example of Multilevel Feedback Queue

• Consider three queues
• Q0 RR with time quantum 8 milliseconds (might
  be good for interactive jobs)
• Q1 RR time quantum 16 milliseconds (still good
  for interactive jobs, but )
• Q2 FCFS low priority batch jobs not
  interactive.
• A new process is put into queue 0 at the getgo.
  (new word!!)
• Given 8 msec.
• Not finished is preempted and (timer
  interrupts), it is moved to tail of queue1.
  (Q0 and Q1 algorithm is round robin)
• If queue 0 is empty, process at head of queue 1
  is given a quantum of 16 msec.
• If this process (formerly head) of queue 1 does
  not finish in 16 msec, it is preempted and moved
  into queue 2, which is scheduled on a FCFS basis
  
• Lower priority queues have their processes
  scheduled only when higher priority queues are
  empty! (run only when queue 0 and quque1 are
  empty.

31
Multilevel Feedback Queues
Processes with short CPU bursts given high
priority. They execute and then release CPU
for their next I/O burst. But (see below) if
this process needs more than 8 msec burst (and lt
24), they are moved to a lower priority
queue. Long processes sink to bottom queue and
essentially serviced as a FCFS process.
32
End of Chapter 5.1