Chapter3:MemoryManagement
Section 3.5.5 discusses the implementation of the buddy system that makes use of the fallback lists gen-
erated here.3.4.2 Architecture-Specific Setup
The initialization of memory management on IA-32 systems is in some aspects a very subtle undertaking
that must overcome a few historical obstacles associated with the processor architecture. These include,
for example, switching the processor from normal mode toprotected modeto grant the CPU access to the
32-bit world — a legacy from the days when compatibility with 16-bit 8086 processors was important.
Similarly, paging is not enabled by default and must be activated manually, which, for instance, involves
fiddling with thecr0register of the processor. However, these subtleties are of no interest to us; you are
referred to the appropriate reference manuals.Notice that our focus on the IA-32 architecture does not mean that the things discussed in
the following will be completely disconnected from all other architectures supported by the kernel.
Quite the opposite is the case: Even if many details will be unique to the IA-32 architecture, many
other architectures do things in a similar way. It’s just necessary to choose one particular architecture as
an example, and since IA-32 has not only been around for quite some time, but was also the architecture
initially supported by Linux, this is reflected in the kernel’s general design. Although there is a clear
tendency of the kernel toward 64-bit platforms, many aspects can still be traced to its IA-32 roots.Another reason why we pick the IA-32 architecture as an example is for practical purposes: Since the
address space is only 4 GiB large, all addresses can be described with comparatively compact hexadec-
imal numbers, which are simply easier to read and work with than the long values required by 64-bit
architectures.Interestingly, the IA-32 architecture does not existas a separate architecture starting with kernel 2.6.24
anymore! It was merged with the AMD64 architecture to form a new, unified x86 architecture. Although
both are now constrained to the single architecture-specific directoryarch/x86, a good many differences
still remain. This is why many files are available in two variants:file_32.cfor IA-32, andfile_64.cfor
AMD64. The existence of two different files for each subarchitecture is something that is only temporarily
tough. Future development will ensure that finally a single file will contain code for both architectures.Since the unified architecture promotes the AMD64 architecture (even more) to one of the most
important architectures supported by the kernel, I will also consider how architecture-specific
details differ for AMD64 compared to IA-32. Owing to the large number of architectures supported by
the kernel, it is not possible to discuss the specificdetails for all of them here. Considering one 32- and
one 64-bit architecture in the following will, however, provide the taste of how Linux does things in both
worlds, and lay the fundamentals to understand the approaches by other architectures.Arrangement of the Kernelin Memory
Before discussing the individual memory initialization operations, we need to examine the situation in
RAM after the boot loader has copied the kernel into memory and the assembler part of the initialization
routines has completed. I concentrate on the default case in which the kernel is loaded to a fixed position
in physical RAM that is determined at compile time.It is also possible to configure the initial position of the kernel binary in physical RAM if the crash dump
mechanism is enabled. Additionally, some embedded systems will require this ability. The configuration