Chapter 2: Process Management and Scheduling
If a large number of read operations is required, this can consume a sizeable amount of time. Since the
process runs in kernel space, it will not be deselected by the scheduler as in the userspace case, taken that
kernel preemption is not enabled. This can be improved by callingcond_reschedin every loop iteration:for (;;)
cond_resched();
/* Read in data */
if (exit_condition)
continue;
The kernel has been carefully audited to find the longest-running functions, and calls tocond_resched
have been put in the appropriate places. This ensures higher responsiveness even without explicit kernel
preemption.Following a long-time tradition for Unix kernels, Linux has supported task states for both interruptible
and uninterruptible sleeps. During the 2.6.25 development cycle, however, another state was added:
TASK_KILLABLE.^35 Tasks in this state are sleeping and do not react to non-fatal signals, but can — in
contrast toTASK_UNINTERRUPTIBLE— be killed by fatal signals. At the time of writing, almost all places
in the kernel that would provide apt possibilities for killable sleeps are still waiting to be converted to the
new form.
The scheduler has seen a comparatively large number of cleanups during the development of kernels
2.6.25 and 2.6.26. A new feature added during this period is real-time group scheduling. This means that
real-time tasks can now also be handled by the group scheduling framework introduced in this chapter.Additionally, the scheduler documentation was moved into the dedicated directoryDocumentation/
scheduler/, and obsolete files documenting the oldO(1) scheduler have been removed. Documentation
on real-time group scheduling can be found inDocumentation/scheduler/sched-rt-group.txt.2.9 Summary
Linux is a multiuser and multitasking operating system, and thus has to manage multiple processes from
multiple users. In this chapter, you have learnedthat processes are a very important and fundamental
abstraction of Linux. The data structure used to represent individual processes has connections with
nearly every subsystem of the kernel.
You have seen how Linux implements the traditionalfork/execmodel inherited fromUnixto create
new processes that are hierarchically related to their parent, and have also been introduced to Linux-
specific extensions to the traditionalUnixmodel in the form of namespaces and theclonesystem call.
Both allow for fine-tuning how a process perceives the system, and which resources are shared between
parent and child processes. Explicit methods that enable otherwise separated processes to communicate
are discussed in Chapter 5.Additionally, you have seen how the available computational resources are distributed between pro-
cesses by the scheduler. Linux supports pluggable scheduling modules, and these are used to implement
completely fair and POSIX soft real-time scheduling policies. The scheduler decides when to switch
between which tasks, and is augmented by architecture-specific routines to implement the context switch-
ing proper.Finally, I have discussed how the scheduler must be augmented to service systems with multiple CPUs,
and how kernel preemption and low-latency modifications make Linux handle time-constrained situa-
tions better.(^35) Actually,TASK_KILLABLEis not a completely new task state, but an extension toTASK_UNINTERRUPTIBLE.Theeffectis,how-
ever, identical.