Chapter 1: Introduction and Overview
When memory is returned by the application, the kernel can easily see by reference to the addresses
whether a buddy pair is reunited and can then merge it into a larger unit that is put back into the buddy
list — exactly the reverse of the splitting process. This increases the likelihood that larger memory blocks
are available.When systems run for longer periods — it is not unusual for servers to run for several weeks or even
months, and many desktop systems also tend to reach long uptime — a memory management problem
known asfragmentationoccurs. The frequent allocation and release of page frames may lead to a situation
in which several page frames are free in the system but they are scattered throughout physical address
space — in other words, there are no largercontiguousblocks of page frames, as would be desirable for
performance reasons. This effect is reduced to some extent by the buddy system but not completely
eliminated. Single reserved pages that sit in the middle of an otherwise large continuous free range can
eliminate coalescing of this range very effectively. During the development of kernel 2.6.24, some effec-
tive measures were added to prevent memory fragmentation, and I discuss the underlying mechanisms
in more detail in Chapter 3.The SlabCache
Often the kernel itself needs memory blocks much smaller than a whole page frame. Because it cannot use
the functions of the standard library, it must define its own, additional layer of memory management that
builds on the buddy system and divides the pages supplied by the buddy system into smaller portions.
The method used not only performs allocation but also implements a generic cache for frequently used
small objects; this cache is known as aslab cache. It can be used to allocate memory in two ways:- For frequently used objects, the kernel defines its own cache that contains only instances of
the desired type. Each time one of the objects isrequired, it can be quickly removed from the
cache (and returned there after use); the slab cache automatically takes care of interaction
with the buddy system and requests new page frames when the existing caches are full. - For the general allocation of smaller memory blocks, the kernel defines a set of slab caches
for various object sizes that it can access using the same functions with which we are familiar
from userspace programming; a prefixedkindicates that these functions are associated with
the kernel:kmallocandkfree.
While the slab allocator provides good performance across a wide range of workloads, some scalability
problems with it have arisen on really large supercomputers. On the other hand of the scale, the overhead
of the slab allocator may be too much for really tiny embedded systems. The kernel comes with two drop-
in replacements for the slab allocator that providebetter performance in these use cases, but offer the
same interface to the rest of the kernel such that it need not be concerned with which low-level allocator
is actually compiled in. Since slab allocation is still the standard methods of the kernel, I will, however,
not discuss these alternatives in detail. Figure 1-9 summarizes the connections between buddy system,
slab allocator, and the rest of the kernel.Swappingand Page Reclaim
Swappingenables available RAM to be enlarged virtually by using disk space as extended memory.
Infrequently used pages can be written to hard disk when the kernel requires more RAM. Once the data