Linux Kernel Architecture

Chapter3:MemoryManagement

Fill bytes speed access to the objects in a slab. Memory access is faster on almost all architectures if aligned

addresses are used. This compensates for the disadvantage of higher memory requirements entailed by

the use of fill bytes.

The management structure holding all the management data (and the list element to link with the

cache lists) is located at the start of each slab. It is immediately followed by an array that includes

an (integer) entry for each object in the slab. Theentries are only of significance if the associated

object isnotallocated. In this case, it specifies the index of the next free object. Because the number

of the free object with the lowest number is also stored in the management structure at the start of

the slab, the kernel is easily able to find all objects currently available without having to use linked

lists or other complicated associations.^29 The last array entry is always an end marker with the value

BUFCTL_END.

Figure 3-47 illustrates the situation graphically.

Management array Slab objects

Unused object Used object

24 6

Figure 3-47: Management of the free objects in a

slab.

In most cases, the size of the slab area (minus the management head) is not divisible by the (possibly

padded) object size without a remainder. Consequently, a little superfluous memory is available to

the kernel and is used to give the slab a ‘‘color‘‘ in the form of an offset as described above. The slab

members of a cache are given different offsets to position the data in different cache lines with the

result that the free memory at the start and end of a slab varies. When the offset is calculated, the ker-

nel must take other alignment factors into account, for instance, alignment of the data on the L1 cache

(discussed below).

The management data can be positioned either on the slab itself or in an external memory area allocated

usingkmalloc.^30 Which alternative the kernel selects depends on the size of the slab and of the objects

used. The corresponding selection criteria are discussed shortly. The association between the manage-

ment data and slab memory is easy to establish because the slab header contains a pointer to the start of

the slab data area (regardless of whether it ison-slaboroff-slab).

Figure 3-48 shows the situation when the data are not on the slab itself (as it is in Figure 3-46) but in

external memory.

And finally, the kernel needs a way of identifying the slab (and therefore the cache in which an object

resides) by reference to the object itself. On the basis of an object’s physical memory address, it is not

difficult to find the associated page and therefore the matchingpageinstance in the globalmem_map

array. As we already know, thepagestructure includes alistelement used to manage the page in

(^29) The original implementation of the slab allocator in the SunOS operating system kernel uses a linked list to keep track of the free
objects.
(^30) This requires special precautions when thekmalloccaches are initialized because obviouslykmalloccannot be invoked there
yet. This and otherchicken-and-eggproblems of slab initialization are discussed below.