next up previous contents index
Next: 8.1 Caches Up: understand-html Previous: 7.4 Freeing A Non-Contiguous   Contents   Index


8. Slab Allocator

In this chapter, the general purpose allocator is described. It is a slab allocator which is very similar in many respects to the general kernel allocator used in Solaris[#!mauro01!#] and is heavily based on the first slab allocator paper by Bonwick[#!bonwick94!#] with many improvements that bear a close resemblance to those described in his later paper[#!bonwick01!#]. We will begin with a quick overview of the allocator followed by a description of the different structures used before giving an in-depth tour of each task the allocator is responsible for.

The basic idea behind the slab allocator is to have caches of commonly used objects kept in an initialized state available for use by the kernel. Without an object based allocator, the kernel will spend much of its time allocating, initialising and freeing the same object. The slab allocator aims to to cache the freed object so that the basic structure is preserved between uses[#!bonwick94!#].

The slab allocator consists of a variable number of caches that are linked together on a doubly linked circular list called a cache chain. A cache, in the context of the slab allocator, is a manager for a number of objects of a particular type like the mm_struct or fs_cache cache and is managed by a struct kmem_cache_s discussed in detail later. The caches are linked via the next field in the cache struct.

Each cache maintains block of contiguous pages in memory called slabs which are carved up into small chunks for the data structures and objects the cache manages. The structure of the allocator as described so far is illustrated in Figure 8.1.



\includegraphics[]{graphs/cache_slab_layout.ps}
[1]
Figure: Layout of the Slab Allocator
[2]


The slab allocator has three principle aims;

To help eliminate internal fragmentation normally caused by a binary buddy allocator, two sets of caches of small memory buffers ranging from 2$^5$ (32) bytes to 2$^{17}$ (131072) bytes are maintained. One cache set is suitable for use with DMA devices. These caches are called size-X and size-X(DMA) where X is the size of the allocation and a function kmalloc() (See Section 8.4.1) is provided for allocating them. With this, the single greatest problem with the low level page allocator is addressed. The sizes caches are discussed in further detail in Section 8.4.

The second task of the slab allocator is to maintain caches of commonly used objects. For many structures used in the kernel, the time needed to initialize an object is comparable or exceeds the cost of allocating space for it. When a new slab is created, a number of objects are packed into it and initialized using a constructor if available. When an object is freed, it is left in its initialized state so that object allocation will be quick.

The final task is hardware cache utilization. If there is space left over after objects are packed into a slab, the remaining space is used to color the slab. By giving objects in different slabs different offsets, they will be assigned difference lines in the CPU cache helping ensure that objects from the same cache will not constantly flush each other. With this, space that would otherwise be wasted fulfills a new function. Linux does not attempt to color pages[#!kessler91!#], or order where objects are placed such as those described for data caches[#!gonzalez95!#] or code[#!hashemi97!#] but the scheme used does help improve cache line usage. Cache colouring is further discussed in section 8.1.5. On an SMP system, a further step is taken to help cache utilization where each cache has a small array of objects for each CPU which is discussed further in Section 8.5.

The slab allocator provides the additional option of slab debugging if the option is set at compile time with CONFIG_SLAB_DEBUG. Two debugging features are providing, red zoning and object poisoning. With red zoning, a marker is placed at either end of the object. If this mark is disturbed, the allocator knows the object was buffer overflowed and reports it. Poisoning an object will fill it with a known pattern at slab creation and after a free. At allocation, this pattern is examined and if it is changed, the allocator knows that the object was used before it was allocated and flags it.


Table 8.1: Slab Allocator API for caches
\begin{table}\begin{center}
\begin{tabularx}{13.5cm}{\vert X\vert}
\hline
\p...
...he from the chain \\ \\
\par
\hline
\end{tabularx}
\end{center} \end{table}




Subsections
next up previous contents index
Next: 8.1 Caches Up: understand-html Previous: 7.4 Freeing A Non-Contiguous   Contents   Index
Mel 2003-01-14