Chapter 2: Process Management and Scheduling
Chapter 2: Process Management and Scheduling.............................
❑ The kernel must decide how much time to devote to each process and when to switch to the next
process. This begs the question as towhichprocess is actually the next. Decisions of this kind are
not platform-dependent.
❑ When the kernel switches from process A to process B, it must ensure that the execution envi-
ronment of B is exactly the same as when it last withdrew processor resources. For example, the
contents of the processor registers and the structure of virtual address space must be identical.
This latter task is extremely dependent on processor type. It cannot be implemented with C only,
but requires help by pure assembler portions.
Both tasks are the responsibility of a kernel subsystem referred to as thescheduler. How CPU time is allo-
cated is determined by the schedulerpolicy, which is totally separate from thetask switchingmechanism
needed to switch between processes.
2.1 Process Priorities
Not all processes are of equal importance. In addition to process priority, with which most readers will
be familiar, there are different criticality classes to satisfy differing demands. In a first coarse distinction,
processes can be split into real-time processes and non-real-time processes.
❑ Hard real-time processesare subject to strict time limits during which certain tasks must be com-
pleted. If the flight control commands of an aircraft are processed by computer, they must be
forwarded as quickly as possible — within a guaranteed period of time. For example, if an air-
craft is on its landing approach and the pilot wants to pull up the nose, it serves little purpose
if the computer forwards the command a few seconds later. By this time, the aircraft may well
be buried — nose first — in the ground. The key characteristic of hard real-time processes is that
they must be processed within a guaranteed time frame. Note that this does not imply that the
time frame is particularly short. Instead, the system must guarantee that a certain time frame is
never exceeded, even when unlikely or adverse conditions prevail.
Linux does not support hard real-time processing, at least not in the vanilla kernel. There are,
however, modified versions such as RTLinux, Xenomai, or RATI that offer this feature. The
Linux kernel runs as a separate ‘‘process’’ in these approaches and handles less important soft-
ware, while real-time work is done outside the kernel. The kernel may run only if no real-time
critical actions are performed.
Since Linux is optimized for throughput and tries to handle common cases as fast as possible,
guaranteed response times are only very hard toachieve. Nevertheless quite a bit of progress
has been made during the last years to decrease the overall kernel latency, that is, the time
that elapses between making a request and its fulfillment. The efforts include the preemptible
kernel mechanism, real-time mutexes, and the new completely fair scheduler discussed in
this book.
❑ Soft real-time processesare a softer form of hard real-time processes. Although quick results are
still required, it is not the end of the world if they are a little late in arriving. An example of a
soft real-time process is a write operation to a CD. Data must be received by the CD writer at a
certain rate because data are written to the medium in a continuous stream. If system loading is
too high, the data stream may be interrupted briefly, and this may result in an unusable CD, far
less drastic than a plane crash. Nevertheless, the write process should always be granted CPU
time when needed — before all other normal processes.