Chapter 18: Page Reclaim and Swapping
Page fault handling is in two parts. First, stronglyprocessor-dependent (assembler) code must be used
to intercept the page fault and query the associated data. Second, a system-independent part of code is
responsible for the further handling of the situation. Because of optimizations used by the kernel when
managing processes, it is not sufficient to simply search for the relevant page in the backing store and
load it into the RAM memory because the page fault may have been triggered for other reasons (see
Chapter 4). For example, copy-on-write pages may be involved; these are copied only when a write
access is executed after a process hasforked. Page faults also occur with demand paging, where the
pages of a mapping are loaded only when actually needed. I ignore these problems here, however, and
focus on the situation in which a swapped-out page must be reloaded into memory.Once again, there’s more to be done than just finding the page in the swap area. As access to the hard
disk is even slower than usual if the read head has to move to a new position (disk seek), the kernel uses
a readahead mechanism to guess which pages will be needed next and also includes these in the read
operation. Thanks to the clustering method mentioned above, the Read/Write head ideally only moves
forward and does not have to jump backward andforward when reading consecutive pages.18.2.5 Shrinking Kernel Caches
Swapping out pages that belong to userspace applications is not the kernel’s only way of freeing memory
space. Shrinking numerous caches often results in good gains. Here, too, the kernel must naturally weigh
up the pros and cons by deciding which data are to be removed from caches and how far the memory
space available for this data may be shrunk without impairing system performance too much. As kernel
caches are generally not particularly huge, the kernel begins to shrink them only as a last resort.As explained in previous chapters, the kernel provides various caches in numerous different areas. This
makes it very difficult to define a general scheme according to which caches can be shrunk because it is
difficult to asses the importance of the data they contain. For this reason, earlier kernel versions featured
numerous caches-specific functions to perform this task for the individual caches.The methods of shrinking the various caches are still implemented separately today since the structures
of the individual variants differ too greatly to allow the adoption of a generally applicable shrinking
algorithm. However, a general framework is now available to manage the cache-shrinking methods.
Functions written to shrink caches are referred to asshrinkersin the kernel and can be registered dynam-
ically. When memory is scarce, the kernel invokes all registered shrinkers to obtain fresh memory.18.3 Managing Swap Areas
Linux is relatively flexible in its support for swap areas. As we have already explained, it is possible
to manage several areas with different priorities, and these may be located both on local partitions and
in files of a predefined size. Swap partitions can also be added and removed dynamically in an active
system without the need for rebooting.The technical differences between the various approaches are made as transparent as possible to
userspace. The modular structure of the kernel also means that the algorithms associated with swapping
can be of a generalized design where the differences between the approaches need only be addressed on
the lower technical levels.18.3.1 Data Structures
As usual, the description begins with a presentation of the central data structures that form the backbone
of implementation and hold all the information and data needed by the kernel. The cornerstone of swap