Slab allocator in Linux

Linux has developed rapidly in recent years. Many small and medium-sized enterprise websites have installed Linux operating systems. This article focuses on Linux kernel memory management, especially the mechanism provided by slab allocation. We will explore the ideas behind slab splitters and introduce the interfaces and usage provided by this method.

Slab Cache

The slab distributor used in Linux is based on an algorithm first introduced by Jeff Bonwick for the SunOS operating system. Jeff's distributor is centered around the object cache. In the kernel, a large amount of memory is allocated to a limited set of objects, such as file descriptors and other common structures. Jeff found that the time required to initialize common objects in the kernel exceeds the time required to allocate and release them.

Therefore, he concluded that the memory should not be released back to a global memory pool, but the memory should be initialized for a specific purpose. For example, if the memory is allocated to a mutex lock, you only need to execute the mutex_init function once when allocating memory for the mutex lock for the first time. Subsequent memory allocation does not need to execute this initialization function, because it is in the desired state after the last release and call of the destructor.

The Linux slab splitter uses this idea and other ideas to build a memory distributor with high efficiency in space and time.

Figure 1 shows the high-level organizational structure of the slab structure. At the highest level is cache_chain, which is a list of links cached by slab. This is very useful for the best-fit algorithm and can be used to find the cache traversal list most suitable for the desired allocation size ). Each element of cache_chain is a reference of the kmem_cache structure called a cache ). It defines an object pool of a given size to be managed.

Figure 1. Main Structure of slab distributor

 

Each cache contains an slabs list, which is a continuous block of memory which is usually a page ). Three slab types exist:

Slabs_full
Fully allocated slab
Slabs_partial
Partially assigned slab
Slabs_empty
Empty slab or no objects are assigned
Note that the slab in the slabs_empty list is the primary alternative for recycling reaping. Through this process, the memory used by slab is returned to the operating system for other users.

Each slab in the slab list is a continuous memory block with one or more consecutive pages), which are divided into objects. These objects are basic elements for allocation and release from a specific cache. Note that slab is the smallest allocation unit for slab distributor operations. Therefore, if you need to expand slab, this is the minimum value of the extension. Generally, each slab is assigned multiple objects.

Because objects are allocated and released from slab, a single slab can be moved between slab lists. For example, when all objects in an slab are used up, they are moved from the slabs_partial list to the slabs_full list. When an slab is completely assigned and an object is released, it is moved from the slabs_full list to the slabs_partial list. After all objects are released, they are moved from the slabs_partial list to the slabs_empty list.

Motivation behind slab

Compared with the traditional memory management mode, the slab cache distributor provides many advantages. First, the kernel usually relies on the allocation of small objects, which will be allocated countless times in the system lifecycle. The slab cache distributor provides this function by caching objects of similar sizes, thus avoiding common fragmentation problems. The slab splitter also supports initialization of common objects, thus avoiding repeated initialization of an object for the same object. Finally, the slab splitter supports hardware cache alignment and coloring, which allows objects in different caches to occupy the same cache row, thus improving the cache utilization and improving performance.