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 interfere with other applications in the system — it usually doesn'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 interrupt occurred. For example, an interrupt is raised when an external block device has transferred data to RAM, 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 interactive behavior and low system latency.
□ If the system is in kernel mode and is processing a 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 priority 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.
One option known as kernel preemption was added to the kernel during the development of kernel 2.5. This option supports switches to another process, if this is urgently required, even during the execution of system calls in kernel mode (but not during interrupts). Although the kernel attempts to execute system calls as quickly as possible, the time needed may be too long for some applications that are reliant on constant data streams. Kernel preemption can reduce such wait times and thus ensure "smoother" program execution. However, this is at the expense of increased kernel complexity because many data structures then need to be protected against concurrent access even on single-processor systems. This technique is discussed in Section 2.8.3.
Was this article helpful?