Linux Kernel memory management slub algorithm (I) Principle

The kernel Management page uses two algorithms: The partner algorithm and the slub algorithm. The partner algorithm manages the memory on pages. However, in most cases, the program does not need a whole page, it is a small memory of several or dozens of bytes. Therefore, another system is required to manage the small memory, which is the slub system. The slub system runs on a partner system and provides a small memory management function for the kernel.

Slub manages memory groups. Each group contains 2 ^ 3, 2 ^ 4 ,... 2 ^ 11 bytes. By default, the 4 K page size has two special groups, 96b and 192b, 11 in total. The reason for this allocation is that if you apply for 2 ^ 12B memory, you can directly apply for a complete page using the interface provided by the partner system.

Slub is equivalent to a retailer who "wholesalers" the memory to the partner system and then goes out for retail. The diagram of the entire slub system is as follows:

Everything comes from the array kmalloc_caches [12]. The definition of this array is as follows:

Struct kmem_cache kmalloc_caches [page_shift] _ cacheline_aligned;

Each array element corresponds to a memory size. You can regard a kmem_cache struct as a retailer with a specific memory size. There are 12 such retailers in the slub system, each "retailer" only stores memory of a specific size. For example, some "retailers" only store 8 bytes of memory, while others only store 16 bytes of memory.

Each retailer (kmem_cache) has two "departments", one is "warehouse": kmem_cache_node, and the other is "Business Hall": kmem_cache_cpu. Only one slab is retained in the "Business Office". Other slab will be swapped out from the warehouse only when there is no idle memory in the Business Office (kmem_cache_cpu.
The so-called slab is the continuous full-page memory wholesale by retailers (kmem_cache). Retailers divide the full-page memory into many small memories and then "retail" them separately, an slab may contain multiple consecutive memory pages. The slab size is related to the retailer.

Related Data Structure:

The physical page is organized into a one-way linked list based on the object size. The object size is specified by the objsize. For example, the size of a 16-Byte object. Each object contains a pointer to the next object, which is the starting address + offset of each object. Each object is as follows:

Void * points to the first address of the next idle object, so that the object is connected to a single-chain table.

When applying for a memory block (object) from the slub system: the slub system treats the memory block as an object.

1. The slub system was just created. This is the first application.
   At this time, the slub system has just been established, and no slab is available in the Business Office (kmem_cache_cpu) and warehouse (kmem_cache_node), as shown in Figure 1:
   
   Therefore, you can only apply for idle memory pages from the partner system and divide these pages into multiple objects. One of the objects is marked as occupied and returned to the user, the remaining objects are marked as idle and saved in kmem_cache_cpu. The freelist variable of kmem_cache_cpu stores the address of the next idle object. 2 indicates applying for a new slab and returning the first idle object to the user. freelist points to the next idle object.

2. The slab stored in the kmem_cache_cpu of slub can be used with idle objects.
   This is the simplest way to directly return an idle object stored in kmem_cache_cpu to the user and point freelist to the next idle object.
   

3. Slub has applied for many consecutive pages. Now there are no idle objects in kmem_cache_cpu, but the partial of kmem_cache_node contains idle objects. Therefore, get the slab with idle objects from the partial variable of kmem_cache_node and return an idle object to the user.
   
   
   In, the slab that has been occupied by kmem_cache_cpu is put into the Warehouse. kmem_cache_node has two double-stranded tables, partial and full, respectively storing slab that is not satisfied (slab has idle objects) and full slab (slab does not have idle objects ). Then, pick out a dissatisfied slab from partial and put it in kmem_cache_cpu.
   
   In, kmem_cache_cpu finds idle objects and returns them to the user.

4. Slub has applied for many consecutive pages. Currently, no idle objects can be used on the physical pages stored in kmem_cache_cpu. In this case, no idle pages exist in kmem_cache_node, you can only apply for slab from the Memory Manager (partner algorithm. Initialize the slab and return the first idle object.
   
   
   Indicates that no idle objects in kmem_cache_node can be used. Therefore, you can only apply for a new slab.
   

   
   Return an idle object in the newly applied slab to the user, and freelist points to the next idle object.
   

When a memory block (object) is released to the slub system, if the slab cached in kmem_cache_cpu is the slab of the object, place the object in the idle linked list, if the slab cached in kmem_cache_cpu is not the slab where the object is located, release the object to the slab where the object is located. When releasing an object, there are three possible situations:

1. Before the object is released, when slab is in full state (all objects in slab are occupied), after the object is released, this is the state in which slab is half full (partail, add the slab to the partial linked list in kmem_cache_node.
   

   
   

2. When slab is in the partial state (slab has both occupied and idle objects), you can directly add this object to the slab's idle queue.
   

3. After the object is released, all the objects in slab are idle. You also need to release the slab.
   

   
   This step generates a completely idle slab, which needs to be released.

The above is the main principle of the slub algorithm.