Linux kernel memory allocation (ii, struct slab and struct kmem_cache)

Previous blog Linux kernel memory allocation (first, the basic concept) is mainly the analysis of the Linux kernel memory allocation and physical page allocation function interface. However, in the actual operation, not all memory requests need a physical page, many just need to allocate a few K-size memory can be. Therefore, a smaller memory allocation function is required. Just start to see this a little bit, but understand it is very simple. Ha ha.

Slab thought

Excerpt from the "Deep Linux device driver kernel mechanism" paragraph: the basic idea of the slab allocator is to use a page allocator to allocate a single or a set of contiguous physical pages, and then on this basis, the whole page is divided into several equal small memory units to meet the needs of small memory space allocation. Of course, in order to effectively manage these small memory units and ensure a high memory usage speed and efficiency.

SLAB Dispenser Structure

First look at the next picture, this is a very classic picture (so it is also intercepted from other places, haha) Basically speaking slab this picture (some of the figures may be a bit different, but they are very similar)

This is a slab allocator composed of struct kmem_cache and struct slab;

From the general direction, each kmem_cache is linked together to form a global doubly linked list, from the cache point to the list, the system can start scanning each kmem_cache from Cache_chain, to find a size of the most appropriate kmem_cache, Then assign an object from the Kmem_cache;

Each kmem_cache (in some places will also call this kmem_cache for the cache, because the object in Kmem_cache is very small (in fact, Kmem_cache has a lot of small), when the memory application, there will be hit the kmem_ The cache, and the CPU cache hit is similar meaning, so also called Kmem_cache Cache) has three linked list, slabs_full that the list of each slab object objects have been allocated; slabs_partial The part of the object that represents the slab in the list is allocated; Slabs_empty indicates that all object objects in the list are not assigned;

Each of these slab is composed of one or more contiguous pages of memory, and each slab is divided into multiple object objects. The allocation and release of objects are performed in slab, so slab can be moved in three linked lists, and if object in slab is allocated, it will be moved to the full list, and if part of the object is assigned, it will be moved to the partial list If all objects are freed, they are moved to the empty list, where slab in the Slabs_empty list may be returned to the system when the system memory is tight.

Kmem_cache distribution

The basic concept is this, the following is a simple code implementation;

First of all the kmem_cache structures are from the Cache_cache, this memory is created when the system is not fully initialized (this structure I see two versions, but the meaning is similar):

Static kmem_cache_t Cache_cache = {         slabs_full:     list_head_init (cache_cache.slabs_full),         slabs_partial:  List_head_init (cache_cache.slabs_partial),         slabs_free:     list_head_init (Cache_cache.slabs_free),         objsize:        sizeof (kmem_cache_t),         flags:          slab_no_reap,         spinlock:       spin_lock_unlocked,         Colour_off:     L1_cache_bytes,         name:           "Kmem_cache",};

System allocation

Let's look at the following two structures:

struct cache_size{     size_t cs_size;     struct Kmem_cache *cs_cachep; }  struct Cache_size malloc_sizes[] = {      {. Cs_size = +}, {. Cs_size = +}, {.     cs_size = +},     {. cs_size =--------},     ...     {. Cs_size = ~0ul},};

At system initialization, the kernel calls the Kmem_cache_init function to traverse the malloc_size array, and each element in the array calls the Kmem_cache_create () function to assign a struct in the Cache_cache kmem_ The cache instance, and assigns the address where the Kmem_cache is located to the Cs_cachep pointer (Malloc_sizes[x]->cs_cachep) in cache_size;

void __init kmem_cache_init (void) {     struct cache_size *sizes = malloc_sizes;//array     struct cache_names *names = Cach E_names;//cache name      ..... while (sizes->cs_size! = Ulong_max) {//from 32 to ~0ul all traverse each element         if (!SIZES->CS_CACHEP)//means not initialized         {            //Kmem _cache_create is to create a kmem_cache           Sizes->cs_cachep = kmem_cache_create (Names->name, Sizes->cs_size,                     Arch_kmalloc_minalign,                     arch_kmalloc_flags| Slab_panic,                     NULL);         }         sizes++;         names++;     }     ..... }

After the initialization of the slab allocator (image from "Deep Linux device Program mechanism"):

As can be seen from the above figure, the first behavior malloc_sizes[] array of all elements, because the malloc_size[] array is stored in the struct cache_size structure elements, so cache_size->cs_size and cache _size->cs_cachep; Each of these Cs_cachep points to a kmem_cache, which indicates that the size of the slab allocation object in the Kmem_cache is cs_size;

Note that this is the slab allocator is just a shell, Kmem_cache below is a three empty list, that is, there is no slab below the kmem_cache and there is not a page more than one object; This is just a rule that says Kmem_ The object size under the cache is fixed to cs_size. As to when to create the slab, the later discussion;

Manually assigned

The so-called manual allocation is in its own program allocation, in fact, is to understand the next kmem_cache_create () function:

struct kmem_cache* kmem_cache_create (const char* name, size_t size, size_t align, unsigned long flags, Void (*ctor) (void *));

The parameter name is a pointer to a string that generates the name of the Kmem_cache, which appears in/proc/slabinfo, and the resulting Kmem_cache object points to the name with a pointer, so make sure that name is in the Kmem_ The cache object is valid within the validity period;

The parameter size is used to specify the slab allocated by the object;

Parameter align is the data alignment, the general use of 0 can be;

The parameter flags is the creation of the Kmem_cache identity bitmask, using 0, which means default;

The argument Void (*ctor) (void*) is a constructor that, when slab assigns a new page, calls the constructor for each memory object in the page;

Return value: Returns a *cachep pointer to the Kmem_cache instance from Cache_cache, and of course the Kmem_cache object is added to the Cache_chain list;

void *kmem_cache_alloc (struct kmem_cache *cachep, gfp_t flags);

Where Cachep is the Kmem_cache object returned by the above kmem_cache_create () function, which returns an idle memory object under CACHEP, and flags is used only when there are no idle objects and a new page is allocated from the physical page;

Kmalloc function

Below the Kmalloc function simple analysis, the code to remove irrelevant things, mainly to illustrate the working principle of the next kmalloc; it is easy to know what the function is doing with the figure below.

void * KMALLOC (size_t size, int flags) {     struct cache_size *csizep = malloc_sizes;//well-defined array     struct Kmem_cache *ca Chep;      while (Size > Csizep->cs_size)//This is the key, traversing from the malloc_sizes array (actually also from the Kmem_cache linked list), to get a cache greater than or equal to size         csizep++ ;      Cachep = csizep->cs_cachep;     Return Kmem_cache_alloc (Cachep, Flags)//The Kmem_cache_alloc () function will be found for the true or the right allocation object

Creation of Slab

As I said earlier, Kmem_cache_create () simply allocates a Kmem_cache instance from the Cache_cache, does not allocate actual physical pages, and of course there is no slab (and no objects). When will you create a slab?

The Kmem_cache is assigned a slab only if the following two conditions are met:

(1) A request has been made to assign a new object; (2) There are no idle objects in the Kmem_cache;

In fact, the essence is: need to get the Kmem_cache next object, and Kmem_cache no idle object, this time will give Kmem_cache assigned a slab. So the newly allocated kmem_cache will call the function to apply for the physical page only when it is required to allocate an object;

The specific allocation process:

The Kmem_cache_grow () function is called first to assign a new slab to Kmem_cache. Where the function calls Kmem_gatepages () obtains a contiguous set of physical pages from the partner system, then calls KMEM_CACHE_SLABGMT () to obtain a new slab structure, and calls Kmem_cache_init_objs () Request a construction method (if defined) for all objects in the new slab, and finally, call Kmem_slab_link_end () to insert the slab structure into the buffer slab the end of the list.

From the allocation of slab can be known, in fact, all the memory is ultimately to the partner system to allocate, it can be known here, these memory is a continuous physical page.

Reprint Address: http://blog.csdn.net/yuzhihui_no1/article/details/47305361

Copyright NOTICE: This article for Bo Master original article, without Bo Master permission not reproduced.

Linux kernel memory allocation (ii, struct slab and struct kmem_cache)