Slab distributor Analysis

Article Title: slab distributor analysis. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.

Good operating system performance depends on the ability of the operating system to effectively manage resources. In the past, heap memory manager was the actual specification, but its performance was affected by the demand for memory fragmentation and memory recovery. In Linux? The kernel uses a method originating from Solaris, but this method has been used for a long time in the embedded system. It allocates memory as objects by size. This article will explore the ideas behind the slab splitter and introduce the interfaces and usage provided by this method.

　　Dynamic Memory Management

The goal of memory management is to provide a way to share memory among users for various purposes. The memory management method should implement the following two functions:

· Minimize the time required for Memory Management

· Maximize available memory for general applications (minimize management overhead)

Memory Management is actually a zero-sum game about trade-offs. You can develop an algorithm that uses a small amount of memory for management, but it takes more time to manage the available memory. You can also develop an algorithm to effectively manage the memory, but use more memory. In the end, the needs of specific applications will lead to the selection of such trade-offs.

Each Memory Manager uses a heap-based allocation policy. In this method, large memory blocks (called heap) are used to provide memory for user-defined purposes. When you need a piece of memory, you are requested to allocate a certain size of memory to yourself. The heap Manager checks the available memory (using specific algorithms) and returns a piece of memory. Some calculation methods used in the search process include first-fit (the first memory block that satisfies the request found in the heap) and best-fit (use the most suitable memory block in the heap that meets the request ). After the user uses the memory, the memory is returned to the heap.

Fragmentation is the fundamental problem of this heap-based allocation policy ). When memory blocks are allocated, they are returned at different times in different order. This will leave some holes in the heap, and it takes some time to effectively manage the idle memory. This algorithm usually has a high memory usage efficiency (allocating the required memory), but it takes more time to manage the heap.

Another method, called buddy memory allocation, is a faster memory allocation technology that divides the memory into two power-level partitions, use the best-fit method to allocate memory requests. When a user releases the memory, the user checks the buddy block to check whether the adjacent memory block has been released. If yes, memory blocks are merged to minimize memory fragments. The time efficiency of this algorithm is higher, but the use of the best-fit method results in a waste of memory.

This article focuses on Linux kernel memory management, especially the mechanism provided by slab allocation.

　　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 kept in the initial state of the needle for a specific object. For example, if the memory is allocated to a mutex lock, you only need to execute the mutex_init function once when the memory is allocated 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 (traversing the list) that best suits the desired allocation size ). Each element of cache_chain is a reference to 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 memory block (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 slab in the slabs_empty list is the primary alternative for 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 (one or more consecutive pages) 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.

[1] [2] [3] Next page