Know your Scheduler
This week I will present some basic concepts about the Linux scheduler
and its operation mode.
The scheduler (or dispatcher) is a kernel component responsible for
coordinating process and thread execution (collectively referred to as
tasks). The scheduler affects the system's overall performance, perhaps
more than any other kernel component, by assigning each task a fair
amount of CPU time based upon the tasks priority and class process.
However, the scheduler also guarantees the lowest priority tasks aren't
starved of CPU time.
Linux implements the preemptive multitasking model, whereby the
scheduler removes a task from the CPU once its allocated time quantum
has expired. Of course, a task may voluntarily surrender -- technically
speaking, yield -- its CPU time if it's waiting for another process to
release a resource. Furthermore, the scheduler reprioritizes tasks. If
a task has already received some CPU time, then it will have lower
priority compared to tasks with identical priority that have not. Under
Linux, a task's priority can range between 20 and -20; the default
priority is 0, and the highest priority is -20. In other words, the
lower the value, the higher the priority (a common source of confusion
for novices). A user can set a priority lower than 0 using the "renice"
command, but the user must have an administrator's privilege.
Linux supports real time tasks as well. A real-time task always takes
priority over all non real-time tasks. In essence, a scheduler sets a
process's state into one of the following modes:
* Running -- A process is the current system process and is
utilizing the system's CPU.
* Running, ready to run -- The process is in the run queue, waiting
for the CPU to become available.
* Waiting, interruptible -- The process is waiting for a lock or an
event. It hasn't disabled incoming signals, so it may be
* Waiting, uninterruptible -- The process is waiting for a lock or
an event. It has disabled signals and therefore, it cannot be
* Stopped -- The process has stopped, typically due to a SIGSTOP
signal. Such a process may resume execution later (i.e., its
state may change to Running) if, for example, it's being executed
under the supervision of a debugger.
* Zombie -- The process is dying (due to a malfunction or power
fault) or has completed its execution. However, its entry hasn't
been removed yet from the system's process table.