Chapter 10

Multiprocessor
and Real-Time
Scheduling
 Agenda
Multiprocessor Scheduling
Real-Time Scheduling
 Linux Scheduling

 Linux Virtual Machine Process Scheduling

Agenda
Multiprocessor Scheduling
 Granularity
 Design Issues
 Process Scheduling
 Thread Scheduling

Real-Time Scheduling
 Background
 Characteristics of Real-Time Operating Systems
 Real-Time Scheduling
 Deadline Scheduling
 Rate Monotonic Scheduling
 Priority Inversion

3
Loosely coupled or distributed multiprocessor, or cluster
• consists of a collection of relatively autonomous systems, each
processor having its own main memory and I/O channels
Functionally specialized processors
• there is a master, general-purpose processor; specialized processors
are controlled by the master processor and provide services to it
Tightly coupled multiprocessor
• consists of a set of processors that share a common main memory
and are under the integrated control of an operating system
Our concern in this section is with the last category, and specifically with
issues relating to scheduling.
Synchronization Granularity
and Processes
 No explicit synchronization
among processes
each user is performing a
 each represents a particular application
separate, independent
application or job
multiprocessor provides the
same service as a
 Typical use is in a time-sharing multiprogrammed
system uniprocessor

because more than one

processor is available, average
response time to the users will
be less
 Synchronization among processes, but at a very gross level

 Good for concurrent processes running on a multiprogrammed

uniprocessor
 can be supported on a multiprocessor with little or no change to user
software
 Single application can be effectively implemented as a collection of
threads within a single process
 programmer must explicitly specify the potential parallelism of an
application
 there needs to be a high degree of coordination and interaction among
the threads of an application, leading to a medium-grain level of
synchronization

 Because the various threads of an application interact so frequently,

scheduling decisions concerning one thread may affect the
performance of the entire application
 Represents a much more complex use of parallelism than is found in
the use of threads

 Is a specialized and fragmented area with many different approaches

  The approach taken will
Scheduling on a depend on the degree of
multiprocessor granularity of
involves three
interrelated issues: applications and the
number of processors
available

actual assignment of
dispatching use of processes to
of a process multiprogramming on processors
individual processors
 Assuming all processors are equal, it is
simplest to treat processors as a pooled static or dynamic needs to be
resource and assign processes to processors determined
on demand

If a process is permanently assigned to one

processor from activation until its advantage is that there may be less
allows group or gang scheduling
completion, then a dedicated short-termoverhead in the scheduling function
queue is maintained for each processor

 A disadvantage of static assignment is that one processor can be idle,

with an empty queue, while another processor has a backlog
 to prevent this situation, a common queue can be used
 another option is dynamic load balancing
 Both dynamic and static methods require some
way of assigning a process to a processor
 Approaches:
 Master/Slave
 Peer
 Key kernel functions always run on a particular processor

 Master is responsible for scheduling

 Slave sends service request to the master

 Is simple and requires little enhancement to a uniprocessor

multiprogramming operating system

 Conflict resolution is simplified because one processor has control of

all memory and I/O resources
Disadvantages:

• failure of master brings down whole system

• master can become a performance bottleneck
 Kernel can execute on any processor

 Each processor does self-scheduling from the pool of available

processes

Complicates the operating system

• operating system must ensure that two processors do

not choose the same process and that the processes are
not somehow lost from the queue
 Usually processes are not dedicated to processors

 A single queue is used for all processors

 if some sort of priority scheme is used, there are multiple queues based
on priority

 System is viewed as being a multi-server queuing architecture

 With static assignment: should individual processors be multiprogrammed
or should each be dedicated to a single process?

 Often it is best to have one process per processor; particularly in the case of
multithreaded programs where it is advantageous to have all threads of a
single process executing at the same time.
 Thread execution is separated from the rest of the definition of a process

 An application can be a set of threads that cooperate and execute

concurrently in the same address space

 On a uniprocessor, threads can be used as a program structuring aid and

to overlap I/O with processing

 In a multiprocessor system kernel-level threads can be used to exploit

true parallelism in an application

 Dramatic gains in performance are possible in multi-processor systems

 Small differences in thread management and scheduling can have an

impact on applications that require significant interaction among threads
 a set of related thread
processes are not
scheduled to run on a set of
assigned to a particular
processors at the same
processor
time, on a one-to-one basis

Load Sharing Gang Scheduling

Four approaches for
multiprocessor thread
scheduling and
processor assignment
are:

provides implicit scheduling the number of threads in a process

defined by the assignment of can be altered during the course of
threads to processors execution

Dedicated Processor Dynamic Scheduling

Assignment
 Simplest approach and carries over most directly from a uniprocessor
environment

Advantages:

• load is distributed evenly across the processors

• no centralized scheduler required
• the global queue can be organized and accessed using any of the
schemes discussed in Operating systems-1

 Versions of load sharing:

 first-come-first-served
 smallest number of threads first
 preemptive smallest number of threads first
 Central queue occupies a region of memory that must be accessed in a
manner that enforces mutual exclusion
 can lead to bottlenecks

 Preemptive threads are unlikely to resume execution on the same processor

 caching can become less efficient

 If all threads are treated as a common pool of threads, it is unlikely that all
of the threads of a program will gain access to processors at the same time
 the process switches involved may seriously compromise performance
 Simultaneous scheduling of the threads that make up a single process

Benefits:

• synchronization blocking may be reduced, less process

switching may be necessary, and performance will increase
• scheduling overhead may be reduced

 Useful for medium-grained to fine-grained parallel applications

whose performance severely degrades when any part of the
application is not running while other parts are ready to run

 Also beneficial for any parallel application

Consider an example in which there are two applications, one
with four threads and one with one thread.
Using uniform time allocation wastes 37.5% of the
processing resource, because when the single-thread
application runs, three processors are left idle (see Figure ).
If there are several one-thread applications, these could all be
fit together to increase processor utilization.
If that option is not available, an alternative to uniform
scheduling is scheduling that is weighted by the number of
threads.
Thus, the four-thread application could be given four-fifths of
the time and the one-thread application given only one-fifth of
the time, reducing the processor waste to 15%.
 When an application is scheduled, each of its threads is assigned to a
processor that remains dedicated to that thread until the application
runs to completion
 If a thread of an application is blocked waiting for I/O or for
synchronization with another thread, then that thread’s processor
remains idle
 there is no multiprogramming of processors

 Defense of this strategy:

 in a highly parallel system, with tens or hundreds of processors,
processor utilization is no longer so important as a metric for
effectiveness or performance
 the total avoidance of process switching during the lifetime of a
program should result in a substantial speedup of that program
Figure 10.3
Application Speedup as a Function of Number of Threads
 For some applications it is possible to provide language and system
tools that permit the number of threads in the process to be altered
dynamically
 this would allow the operating system to adjust the load to improve
utilization

 Both the operating system and the application are involved in

making scheduling decisions
 The scheduling responsibility of the operating system is primarily
limited to processor allocation
 This approach is superior to gang scheduling or dedicated processor
assignment for applications that can take advantage of it
Agenda
Multiprocessor Scheduling
 Granularity
 Design Issues
 Process Scheduling
 Thread Scheduling

Real-Time Scheduling
 Background
 Characteristics of Real-Time Operating Systems
 Real-Time Scheduling
 Deadline Scheduling
 Rate Monotonic Scheduling
 Priority Inversion

27
 The operating system, and in particular the
scheduler, is perhaps the most important
component
• control of laboratory experiments
• process control in industrial plants
• robotics
Examples: • air traffic control
• telecommunications
• military command and control
systems
 Correctnessof the system depends not only
on the logical result of the computation but
also on the time at which the results are
produced.
 Tasks or processes attempt to control or
react to events that take place in the outside
world.
 Theseevents occur in “real time” and tasks
must be able to keep up with them.
 Hard real-time task Soft real-time task
 Has an associated
 one that must meet deadline that is
its deadline. desirable but not
 otherwise it will mandatory
cause unacceptable  It still makes sense to
damage or a fatal schedule and
error to the system. complete the task
even if it has passed
its deadline.
 Periodic tasks
 requirement may be stated as:
 once per period T
 exactly T units apart

 Aperiodic tasks
 has a deadline by which it must finish or start
 may have a constraint on both start and finish
time
Real-time operating systems have
requirements in five general areas:
Determinism
Responsiveness
User control
Reliability
Fail-soft operation
 Concerned with how long an operating
system delays before acknowledging an
interrupt.
 Operations are performed at fixed,
predetermined times or within
predetermined time intervals
 The extent to which an operating
system can deterministically
satisfy requests depends on:

•the speed with which it can respond to

interrupts.

•whether the system has sufficient capacity

to handle all requests within the required time.
 Together with determinism make up the
response time to external events
 critical for real-time systems that must meet
timing requirements imposed by individuals,
devices, and data flows external to the system.
 Concerned with how long, after
acknowledgment, it takes an operating system
to service the interrupt.
Responsiveness includes:

• amount of time required to initially

handle the interrupt and begin execution
of the interrupt service routine (ISR)
• amount of time required to perform the
ISR
• effect of interrupt nesting
 Generally much broader in a real-time operating
system than in ordinary operating systems
 It is essential to allow the user fine-grained
control over task priority
 User should be able to distinguish between hard
and soft tasks and to specify relative priorities
within each class
May allow user to specify such characteristics as:
 paging or process swapping
 what
processes must always be resident in main
memory
 what disk transfer algorithms are to be used
 whatrights the processes in various priority
bands have
 More important for real-time systems than
non-real time systems
 Real-time systems respond to and control
events in real time so loss or degradation of
performance may have catastrophic
consequences such as:
 financial loss
 major equipment damage
 loss of life
A characteristic that refers to the ability of a
system to fail in such a way as to preserve as
much capability and data as possible
 Important aspect is stability
 a real-time system is stable if the system
will meet the deadlines of its most critical,
highest-priority tasks even if some less
critical task deadlines are not always met
The heart of a real-time system is the
short-term task scheduler.

In designing such a scheduler, fairness

and minimizing average response time are
not important.

What is important: is that all hard real-time

tasks complete (or start) by their deadline
and that as many as possible soft real-time
tasks also complete (or start) by their
deadline.
Scheduling of Real-Time Process

In this case, the scheduling time will generally be

unacceptable for real-time applications.
This could lead to a delay of several seconds if a slow,
low-priority task were executing at a critical time.
Again, this approach is not acceptable.
A more promising approach is to combine priorities with clock-
based interrupts. Preemption points occur at regular intervals.
When a preemption point occurs, the currently running
task is preempted if a higher-priority task is waiting.
This would include the preemption of tasks
that are part of the operating system kernel.

Such a delay may be on the order of several

milliseconds ( Figure 10.4c ).

While this last approach may be adequate

for some real-time applications, it will not be
enough for more demanding applications.
In those cases, the approach that has been
taken is sometimes referred to as immediate
preemption.

In this case, the operating system responds

to an interrupt almost immediately, unless
the system is in a critical-code lockout
section.

Scheduling delays for a real-time task can

then be reduced to 100 μs or less.