Chapter3:MemoryManagement
in the cache and allocates it again as quickly as possible (in response to the next request). Only when the
per-CPU caches are empty are free objects from the slabs used to refill them.
This results in a three-level hierarchy for object allocation within which both the allocation cost and the
negative impact of the operation on caches and TLBs rise from level to level:
- Per-CPU objects in the CPU cache.
- Unused objects from an existing slab.
- Unused objects from a new slab just reserved using the buddy system.
Fine Structureof Slabs
Objects are not listed continuously in slabs but are distributed according to a rather complicated scheme.
Figure 3-46 illustrates the details.
Manage-
ment
head
...
BUFCTL_END
Management
of free objects
Color
Space
Unused
Memory Mappings
Free Used Free ...
Fill bytes for
alignment
Object Size
Figure 3-46: Fine structure of a slab.
The size used for each object does not reflect its exact size. Instead, the size is rounded to fulfill certain
alignment criteria. Two alternatives are possible:
❑ Using the flagSLAB_HWCACHE_ALIGNat slab creation time, the slab user can request that objects
are aligned to hardware cache lines. The alignment is then performed along the value returned
bycache_line_size, which returns the processor-specific size of the L1 cache.
If objects are smaller than half of the cache line size, then more than one object is fit into one
cache line.
❑ If alignment along hardware cache lines is not requested, then the kernel ensures that objects are
aligned withBYTES_PER_WORD— the number of bytes needed to represent avoidpointer.
On 32-bit processors, 4 bytes are required for avoidpointer. Consequently, for an object with 6 bytes,
8 = 2 ×4 bytes are needed, and objects with 15 bytes require 16= 4 ×4 bytes. The superfluous bytes are
referred to asfill bytes.