Chapter3:MemoryManagement
The termcoloris used in the metaphorical sense. It has nothing to do with colors
but represents a certain offset by which the objects in the slab are shifted to place
them in a different cache line.Where does the nameslaballocator come from? The objects managed in each cache are combined into
larger groups covering one or more contiguous page frames. Such groups are calledslabs; each cache
consists of several such slabs.3.6.1 Alternative Allocators
Although the slab allocator works well for many possible workloads, there are naturally situations in
which it fails to provide optimal performance. Problems arise when slab allocation is used on machines
that range on the borders of the current hardware scale: tiny embedded systems and large, massively
parallel systems equipped with huge amounts of RAM. In the second case, the large amount of metadata
required by the slab allocator can become a problem: developers have reported that many gigabytes of
memory are required only for the slab data structures on large systems. For embedded systems, the total
footprint and complexity of slab allocation can simply be too much.To cope with such situations, two drop-in replacements for the slab allocator were added during the
development of kernel 2.6:❑ Thesloballocator is especially optimized for low code size. It is centered around a simple linked
lists ofblocks (thus its name). To allocate memory, a likewise simple first-fit algorithm is used.
With only roughly 600 lines, the total footprint of the slob allocator is very small. Naturally, it
is not the most efficient allocator in terms of speed and is definitely not designed to be used on
large-scale systems.
❑ Thesluballocator tries to minimize the required memory overhead by packing page frames into
groups and to manage these groups by overloading unused fields instruct page. While this
certainly does not simplify the definition of this structure, as you have seen before, the effort is
justified by the better performance of slub in contrast to slab on large machines.Since slab allocation is the default option used by mostkernel configurations, alternative allocators are
not discussed in detail. It is, however, important to emphasize that the rest of the kernel need not be
concerned about which low-level allocator is chosen. The visible front end is identical for all allocators.
Each must implement a certain set of functions for memory allocation and caching:❑ kmalloc,__kmalloc,andkmalloc_nodeas general (node-specific) allocation functions.
❑ kmem_cache_alloc,kmem_cache_alloc_nodeas (node-specific) providers of specific kernel
caches.The behavior of these functions is included in the following discussion of the slab allocator. Using these
standard functions, the kernel can provide furtherconvenience functions that do not require specific
knowledge about how memory is managed internally — for instance,kcallocto allocate memory for
arrays, orkzallocto allocate a memory region that is filled with zero bytes. The situation is illustrated
in Figure 3-43.Regular kernel code just needs to includeslab.hto enjoy all standard kernel functions for memory
allocation. The build system will ensure that the allocator chosen at compile time is used to fulfill the
desired requests.