Chapter 4: Virtual Process Memory
Chapter 4: Virtual Process Memory..........................................
❑ Thefork-execmodel used underUnixto generate new processes (described in Chapter 2)
is not very powerful if implemented carelessly. The kernel must therefore concentrate on
managing user address spaces as efficiently as possible by resorting to a few tricks.Most of the ideas discussed below are based on the assumption that the system has amemory management
unit(or MMU) that supports the use of virtual memory. This is, in fact, the situation on all ‘‘normal‘‘
processors. However, during the development of Linux 2.5, three architectures that do not provide an
MMU were added to the kernel sources — V850E, H8300, and m68knommu. Another one (blackfin)
was added during the development of kernel 2.6.22. Some of the functions examined below are not
available on these CPUs, and the interface to the outside returns error messages because the underlying
mechanisms are not implemented in the kernel and cannot be implemented owing to the lack of processor
support. The information below covers only machines with MMU. I do not deal with the oddities and
modifications needed for MMU-less architectures.4.2 Virtual Process Address Space
The virtual address space of each process starts at address 0 and extends toTASK_SIZE - 1;thekernel
address space begins above this. On IA-32 systems with 2^32 =4 GiB, the total address space is usually
split in a 3:1 ratio on which we focus in the information below. The kernel is assigned 1 GiB, while 3 GiB
is available toeachuserspace process. Other ratios are possible but yield benefits only on very specific
configurations and with certain work loads, as discussed above.A very important aspect relating to system integrity is that user programs may access only the lower part
of the overall address space butnotthe kernel part. Neither is it possible for a user process to manipulate
parts of the address space of another process without previous ‘‘agreement,’’ simply because these parts
are invisible to it.The contents of the virtual address space portion of the kernel are always the same regardless of which
user process is currently active. Depending on hardware, this is achieved either by manipulating the page
tables of user processes so that the upper part of the virtual address space always appears to be identical
or by instructing the processor itself to provide a separate address space for the kernel, which is mapped
above each user address space. Recall that this is visualized in Figure 1-3 in the Introduction.The virtual address space is made up of many sections of varying sizes that serve different purposes and
must be handled differently. For example, in most cases, it is not permitted to modify the text segment,
but it must be possible to execute its contents. On the other hand, it must be possible to modify the
contents of a text file mapped into the address space but not to execute such contents as this doesn’t
make sense — it’s just data and not machine code.4.2.1 Layout of the Process Address Space
The virtual address space is populated by a number ofregions. How they are distributed is architecture-
specific, but all approaches have the following elements in common:❑ The binary code of the code currently running. This code is normally referred to astextand the
area of virtual memory in which it is located as atext segment.^1
❑ The code of dynamic libraries used by the program.(^1) This isnotthe same as a hardware segment, which is featured in some architectures and acts as a separate address space. It is simply
the linear address space area used to hold the data.