Linux kernel memory management algorithm Buddy and Slab

With the study of the first two sections, I believe that readers already know that all operations of the CPU are based on virtual addresses (the virtual addresses here are divided into kernel-mode virtual addresses and user-mode virtual addresses), and the memory management seen by the CPU is correct. Page management, let's take a look at the classic algorithm used to manage pages - Buddy.


Buddy Allocation Algorithm

640?wx_fmt=png&wxfrom=5&wx_lazy=1&retryload=1

Assuming that this is a continuous page frame, the shaded part indicates the page frame that has been used, and now it is necessary to apply for a continuous 5 page frames. At this time, if 5 consecutive free page frames cannot be found in this memory, it will go to another segment of memory to find 5 consecutive page frames. In this way, a waste of page frames will be formed over time. In order to avoid this situation, the Buddy system algorithm (Buddy system) is introduced into the Linux kernel. Group all free page frames into 11 block linked lists, each block linked list contains page frame blocks of size 1, 2, 4, 8, 16, 32, 64, 128, 256, 512 and 1024 consecutive page frames, respectively . A maximum of 1024 contiguous page frames can be applied for, corresponding to 4MB of contiguous memory. The physical address of the first page frame of each page frame block is an integer multiple of the block size, as shown in the figure:

640?wx_fmt=png

Suppose you want to apply for a block of 256 page frames, first look for a free block from the linked list of 256 page frames, if not, go to the linked list of 512 page frames to find, if found, divide the page frame block into 2 256 A block of page frames, one is allocated to the application and the other is moved to a linked list of 256 page frames. If there is still no free block in the linked list of 512 page frames, continue to search the linked list of 1024 page frames, if there is still no free block, return an error. When the page frame block is released, it will actively merge two consecutive page frame blocks into a larger page frame block.

It can be seen from the above that the Buddy algorithm has been doing the action of unpacking and unpacking the page frame. Buddy's algorithm is awesome because it uses any positive integer in the world that can be composed of the sum of 2^n. This is also the essence of the Buddy algorithm to manage the free page table.
The information of free memory can be obtained by the following command:

640?wx_fmt=png

You can also observe the buddy status by echo m > /proc/sysrq-trigger, which is consistent with the information in /proc/buddyinfo:

640?wx_fmt=png


CMA

Attentive readers may find that when the Buddy algorithm disassembles and assembles the memory, it will cause fragmentation, so that the memory will not have large blocks of contiguous memory, but all small blocks of memory. Of course, this has no effect on the application (we mentioned earlier that the discontinuous physical address can be contiguous on the virtual address by using the page table), but the kernel state has no way to obtain a large block of contiguous memory (such as DMA, Camera, GPUs all require large blocks of memory with contiguous physical addresses).

In embedded devices, CMA is generally used to solve the above problems . The full name of CMA is contiguous memory allocator. Its working principle is that a section of memory is reserved for the driver to use, but when the driver is not in use, the CMA area can be allocated to user processes for anonymous memory or page cache. When the driver needs to use it, the memory occupied by the process is reclaimed or migrated to free up the previously occupied reserved memory for the driver to use.


Slab

In Linux , the buddy system manages and allocates memory in units of pages. But the actual demand is in bytes. If we need to apply for 20Bytes , we can't allocate a page! Wouldn't that be a serious waste of memory. So how should it be distributed? The slab allocator came into being, designed for small memory allocation. The slab allocator allocates memory in Bytes . However , the slab allocator is not separated from the partner system, but is further subdivided into small memory allocations based on the large memory allocated by the partner system. Let's look at a picture first:

640?wx_fmt=png

kmem_cache is a linked list of cache_chain, describing a cache, each cache contains a list of slabs, which is usually a contiguous block of memory. There are 3 kinds of slabs:

  • slabs_full (fully allocated slabs)

  • slabs_partial (partially allocated slabs)

  • slabs_empty (empty slabs, or no objects are allocated).

Slab is the smallest unit of slab allocator. In the implementation, a slab consists of one or more consecutive physical pages (usually only one page). A single slab can be moved between slab linked lists. For example, if a half-full slab becomes full after being allocated an object, it will be deleted from slabs_partial and inserted into slabs_full at the same time.


For further explanation, here is an example to illustrate that a segment of memory described by the struct kmem_cache structure is called a slab cache pool. A slab buffer pool is like a box of milk. There are many bottles of milk in a box of milk, and each bottle of milk is an object . When allocating memory, it's like taking a bottle from a milk crate. There's always a day when it's over. When the box is empty, you need to go to the supermarket and buy another box. The supermarket is equivalent to a partial linked list, and the supermarket stores many boxes of milk. If the supermarket is also sold out, it will naturally be purchased from the manufacturer and then sold to you. The manufacturer is equivalent to the partner system.


You can view the slab cache information with the following command:

640?wx_fmt=png


Summarize

From the memory DDR is divided into different ZONEs, to the Pages accessed by the CPU to map the ZONEs through the page table, and then to the management of these Pages through the Buddy algorithm and the Slab algorithm, we should be able to understand the following figure from a sensory point of view:

640?wx_fmt=png


Recommended reading:

How does the CPU access memory?

Distribution of physical and virtual addresses


Swipe lightly and welcome to pay attention~

640?wx_fmt=jpeg

640?wx_fmt=gif



Guess you like

Origin http://43.154.161.224:23101/article/api/json?id=324440026&siteId=291194637