Scheduling in Linux

Written by Ian on Tuesday 27/11/07


In Linux, there is a schedule() function in the kernel source code (kernel/sched.c)
which implements scheduling, and which you can look through/edit.


This is actually an amazing and well-thought out piece of code, and is a good example of a scheduler that can perform well whether there are 200 processes or just 2.


The scheduler handles interrupts, sorts through and chooses from the set of runnable
tasks by priority and other metrics, and switches to the chosen task.
schedule() is executed at task dispatch points (ret_from_sys_call) and
by explicit sleep instructions encountered in running code.

The Linux function sched_setscheduler() sets the scheduling policy
and parameters for the specified PIDs. You can call this in your programs.
There are three scheduling policies in standard Linux (some embedded
flavours provide alternatives, and some provide none!).
Normally you don't touch the scheduling and don't touch the priorities,
on a desktop machine, but for efficient hard real-time embedded systems
it is often necessary to explicitly set priorities and scheduling algorithms.
Otherwise you would need a grossly over-powered CPU.


SCHED_OTHER: is the default time-sharing preemptive scheduler that
uses a process nice level and a counter (how long has
a process been waiting...)

SCHED_FIFO: is first-in, first-out preemptive non-timesliced scheduler
that will run a high priority process to completion, and
allows a newly-runnable process to preempt lower
priority processes

SCHED_RR: adds round-robin capabilities to SCHED_FIFO in that
processes don't run to completion, but are time-sliced
so that other processes get a chance to run


You will need root access to select these or set a higher than default
process priority level.


WARNING!
Note this piece of good advice from the sched_setscheduler() man page:


As a non-blocking end-less loop in a process scheduled under
SCHED_FIFO or SCHED_RR will block all processes
with lower priority forever, a software developer should always
keep available on the console a shell scheduled under a higher
static priority than the tested application.
This will allow an emergency kill of tested real-time
applications that do not block or terminate as expected.