Chapter 2: Process Management and Scheduling
reboot. This can be seen by reading the output of process tools such aspsortop.Thisishardlyaproblem
as the residual data take up little space in the kernel.
2.2.1 Preemptive Multitasking
The structure of Linux process management requires two further process state options — user mode and
kernel mode. These reflect the fact that all modern CPUs have (at least) two different execution modes,
one of which has unlimited rights while the other is subject to various restrictions — for example, access
to certain memory areas can be prohibited. This distinction is an important prerequisite for creating
locked ‘‘cages,’’ which hold existing processes and prevent them from interfering with other parts of the
system.
Normally the kernel is in user mode in which it may access only its own data and cannot therefore inter-
fere with other applications in the system — it usuallydoesn’t even notice that there are other programs
besides itself.
If a process wants to access system data or functions (the latter manage the resources shared between all
processes, e.g., filesystem space), it must switch to kernel mode. Obviously, this is possible only under
control — otherwise all established protection mechanisms would be superfluous — and via clearly
defined paths. Chapter 1 mentioned briefly that ‘‘system calls‘‘ are one way to switch between modes.
Chapter 13 discusses the implementation of such calls in depth.
A second way of switching from user mode to kernel mode is by means of interrupts — switching is
then triggered automatically. Unlike system calls, which are invoked intentionally by user applications,
interrupts occur more or less arbitrarily. Generally, the actions needed to handle interrupts have nothing
to do with the process executing when the interruptoccurred. For example, an interrupt is raised when
an external block device has transferred data toRAM, although these data may be intended for any
process running on the system. Similarly, incoming network packages are announced by means of an
interrupt. Again, it is unlikely that the inbound package is intended for the process currently running.
For this reason, Linux performs these actions in such a way that the running process is totally unaware
of them.
The preemptive scheduling model of the kernel establishes a hierarchy that determines which process
states may be interrupted by which other states.
❑ Normal processes may always be interrupted — even by other processes. When an important
process becomes runnable — for example, an editor receives long-awaited keyboard input — the
scheduler can decide whether to execute the process immediately, even if the current process is
still happily running. This kind of preemption makes an important contribution to good interac-
tive behavior and low system latency.
❑ If the system is in kernel mode and is processinga system call, no other process in the system
is able to cause withdrawal of CPU time. The scheduler is forced to wait until execution of the
system call has terminated before it can select another process. However, the system call can be
suspended by an interrupt.^1
❑ Interrupts can suspend processes in user mode and in kernel mode. They have the highest prior-
ity because it is essential to handle them as soon as possible after they are issued.
(^1) It is possible to disable almost all interrupts for important kernel actions.