Linux Scheduling

CS 4510

Scheduling Policy
The

scheduling algorithm of traditional Unix

systems must fulfill several conflicting
objectives

Fast process response time

Good throughput for background jobs
Avoidance of process starvation
Etc.

The

set of rules used to determine when and

how to select a new process to run is called
the scheduling policy

Scheduling Policy
Linux

scheduling is based on time

sharing
CPU time is divided into slices, one for
each runnable process
If a currently running process is not
terminated when its quantum expires,
a process switch may take place

Scheduling Policy
The

scheduling policy ranks processes

according to their priority
In Linux, process priority is dynamic.
Processes that have been denied the use
of the CPU for a long time are boosted by
dynamically increasing their priority
Long running processes have their priority
lowered.

Classes of Processes
Interactive

Processes

Must respond quickly

Typically

between 50 and 150 ms

Variance must also be bounded

Includes:
Command

Shells
Text editors
Graphical applications

Classes of Processes
Batch

processes

Do not need user interaction

Often penalized by the Scheduler
Includes:
Compilers
Database

Search Engines
Scientific Computations

Classes of Processes
Real-time

processes

Have very stringent scheduling requirements

Should never be blocked by lower-priority
processes
Needs
Short

guaranteed response time

Minimum variance

Includes
Video

and sound applications

Robot controllers
Data Collectors from physical sensors

Process Preemption
If

a process enters the TASK_RUNNING state,

the kernel checks whether its dynamic
priority is greater than the priority of the
currently running process.
If so, the current process is interrupted and
the scheduler is invoked to select another
process to run.
A preempted process is not suspended it
remains in the TASK_RUNNING state; it
simply no longer uses the CPU

How Long Should a Quantum

Last?
If

its too short, system overhead is high

If too long, processes no longer appear to be
responsive
Long quantum durations do not usually
degrade response time
Higher priority process, such as interactive
process, will quickly interrupt lower priority
processes like batch processes

The

choice of quantum duration is always a

compromise
Choose a duration as long as possible while
keeping good system response time.

The Scheduling Algorithm

CPU

time is divided into epochs.

Every process has a time quantum whose

duration is computed when the epoch
begins
The quantum is the maximum CPU time
assigned to the process in that epoch
A process can be selected several times
from the scheduler in the same epoch, as
long as its quantum is not exhausted

The Scheduling Algorithm

Base

Time Quantum

Assigned by the scheduler if a process has

exhausted its time quantum in the
previous epoch
Users can change the base time quantum
by using the system calls nice( ) and
setPriority( )
A new process inherits the base time
quantum of its parent

The Scheduling Algorithm

Process

Priorities

Static priority
Assigned

by the users to real-time process

Ranges from 1 to 99
Never changed by the scheduler

Dynamic priority
Applies

only to conventional processes

Sum of
Base time quantum
Ticks of CPU time left to the process before its
quantum expires

CPUs Data Structures

nice

Determines the length of the process time

quantum when a new epoch begins. Ranges
between -20 and +19
Negative

values correspond to high priority processes

counter

Number of ticks of CPU time left to the process

before its quantum expires
need_resched

A flag checked by ret_from_sys_call( ) to decide

whether to invoke the schedule( ) function

The schedule( ) function

Direct Invocation

The scheduler is invoked directly when the

current process must be blocked right away

Steps
1. Inserts current in the proper wait queue
2. Changes state to TASK_INTERRUPTIBLE or
TASK_UNINTERRUPTIBLE
3. Invokes schedule( )
4. Goto step 2 unless resource is available
5. Once resource is available, removes current
from wait queue

The schedule( ) Function

Lazy

Invocation

The scheduler can also be invoked in a lazy way by

setting the need_resched field of current to 1
A check on this value is always made before resuming
execution of a User Mode process
Schedule will be invoked at some time in the near future
Lazy

invocation is performed in the following cases

When current has used up its time quantum

When a process is woken up and its priority is higher
than the current process
When a sched_yield( ) system call is issued

Actions Performed Before

a Process Switch
The

key outcome of the function is to

set a local variable next so that it
points to the PCB of the process
selected to replace current

Actions Performed Before

a Process Switch
The

schedule function starts with the

following code
prev = current;
this_cpu = prev->processor;
sched_data = &aligned_data[this_cpu]

Actions Performed Before

a Process Switch
Before

starting to look at the runnable

processes, schedule( ) must disable
the local interrupts and acquire the
spin lock that protects the run queue.

spin_lock_irq(&runqueue_lock)

Actions Performed Before

a Process Switch

If prev is not in the TASK_RUNNING state,

schedule( ) was directly invoked by the process
itself because it had to wait on some external
resource; therefore, prev must be removed from the
runqueue
if (prev->state != TASK_RUNNING)
del_from_runqueue(prev);
The function also resets the need_resched field of
current, just in case the scheduler was activated in
the lazy way:
prev->need_resched = 0;

Actions Performed Before

a Process Switch
Now

schedule scans the runqueue to find the

process to be executed in the next quantum.

repeat_schedule:
next = init_tasks[this_cpu];
c = -1000;
list_for_each(tmp, &runqueue_head)
P = list_entry(tmp, struct task_struct, runlist);
int weight = goodness(p, this_cpu, prev->active_mm);
If (weight > c) c = weight, next = p;

The goodness( ) function returns an integer that

denotes the priority of the process passed as a
parameter

Actions Performed Before

a Process Switch
While

scanning processes in the

runqueue, schedule( ) considers only
those that are
Runnable on the executing CPU
(cpus_allowed

& 1<<this_cpu)

Not alreading on some other CPU

(cpus_runnable

& 1<<this_cpu)

Actions Performed Before

a Process Switch
If

the run-queue is empty, next points

to the swapper kernel thread
associated with the executing CPU.
It is also possible that the best
candidate turns out to be the old
current process -- prev

Actions Performed Before

a Process Switch

If C is set to 0, then all processes have exhausted

their time quantum. When this happens a new
epoch begins, and all processes are assigned a
fresh quantum
(if !c)
for_each_task(p)
p->counter = (p->counter >> 1) +
(20 p->nice) / 4 + 1
goto repeat_schedule

Suspended or stopped process have their dynamic

priorities periodically increased. This gives a higher
priority to interactive processes

Actions Performed Before

a Process Switch
The

last thing that is done before the

process switch is to be sure that the
processes memory is set up properly

Actions Performed after a

Context Switch
Schedule(

) invokes
_schedule_tail()
This function checks whether some
other process has set the
need_resched field of prev while it was
not running. In this case, the whole
schedule function is reexecuted from
the beginning.

Actions Performed After

a Process Switch
Most

of the functions performed by

schedule( ) after the context switch
are primarily important for multiprocessor systems.

Goodness Values
weight

== -1

weight

== 0

p is the previous process, and its SCHED_YIELD

flag is set. The process will be selected only if no
other runnable processes are in the runqueue
p is a conventional process that has exhausted
its quantum

<= weight <= 77

p is a conventional process that has not

exhausted its quantum

weight

>= 1000

p is a real-time process

Goodness Values
The

goodness value is computed as

follows

weight

= p->counter +20 - p->nice;

bonus is also given to process running

on the same CPU and those which share
the same memory space as the kernel