Slab allocation mechanism of nginx principle analysis

1 Introduction

It is well known that the operating system uses partner systems to manage memory, not only causing a lot of memory fragmentation, but also inefficient processing. Slab is a memory management mechanism, it has high processing efficiency, but also effectively avoids the generation of memory fragmentation, the core idea is pre-allocation. The memory is managed according to size, and when a chunk size is requested for memory, the allocator allocates a block of memory from the size collection, and when a size of memory is released, the memory block is put back to the original collection instead of being released to the operating system. When you apply for the same size of memory, you can reuse the memory block (block) that was previously reclaimed, thus avoiding the generation of memory fragments. [Note: Because the slab processing process more details, here just to do a theoretical explanation]

2 General structure



Figure 1 Slab Memory structure

3 Processing Flow

1: The slab management mechanism divides memory into slab headers, slot arrays, pages arrays, assignable spaces, wasted space modules for separate management, and the functions and roles of each module are as follows:

Slab Header: Contains summary information for slab management, such as minimum allocation unit (min_size), displacement (min_shift) for the minimum allocation unit, number of page group addresses (pages), free page list (zero), start address of the assignable space (start), Memory block End address (end) and so on (as shown in code 1), memory allocation, recycling, positioning, and so on are dependent on this data during the memory management process.

Slot array: Each member of the slot array is responsible for allocating and reclaiming a fixed-size block of memory (block), respectively. In Nginx Slot[0]~slot[7] is responsible for the interval in [1~8], [9~16], [17~32], [33~64], [65~128], [129~256], [257~512], [513~1024] byte size of memory allocation, However, the size of each block is the upper limit of each interval (8, 16, 32, 64, 128, 256, 512, 1024) to facilitate the allocation and recycling of memory blocks (block). For example, if the application process requests 5 bytes of space, because 5 is within the [1~8] interval, so slot[0] is responsible for the allocation of the memory, but the limit of the interval [1~8] is 8, so even if the application 5 bytes, but still allocate 8 bytes to the application process. And so on: If the application is 12 bytes, 12 is in the interval [9~16], the upper limit is 16, so the slot[1] allocates 16 bytes to the application process, if the application 50 bytes, 50 is in the interval [33~64] between the upper limit of 64, so by slot[2] Allocate 64 bytes to the application process; If the application is 84 bytes, 84 is in the interval [65~128], the upper limit is 128, so the slot[3] allocates 128 bytes; If the application is 722 bytes, 722 is in the interval [513~1024], the upper limit is 1024, so the slot[7] allocates 1024 bytes.

Pages array: Each member of the pages array is responsible for querying, allocating, and reclaiming pages in the assignable space, and the process can refer to the description of Section 3.2.

Assignable space: Slab logically divides the assignable space into M-memory pages with a size of 4K per page. Each page of memory corresponds to the members of the pages array, and each member of the pages array is responsible for allocating and reclaiming each memory page.

Wasted space: According to the size of each page 4K to divide the space, to meet the space of 4K, will be allocated as a space to be managed by the pages array, and the last remaining less than 4K of memory will be discarded, that is wasted!

3.1 Initialization process

The initialization phase mainly completes the division of slot headers, slot arrays, pages arrays, assignable spaces, and wasted space, and the partitioning of each region can refer to the description of Figure 1 and the function of each module. The slab structure in Nginx is as follows:

[HTML] View Plaincopyprint?





typedef struct {

size_t Min_size; /* Minimum allocation unit */

size_t Min_shift; /* Displacement corresponding to the minimum allocation unit */



ngx_slab_page_t *pages; /* Page Group */

ngx_slab_page_t free; /* Free Page list */



U_char *start; /* The starting address of the assignable space */

U_char *end; /* End Address of memory block */



.../* Other variable members (omitted) */

}ngx_slab_pool_t

typedef struct {    size_t            min_size;     /* Minimum allocation unit */    size_t            min_shift;    /* Displacement corresponding to the minimum distribution unit */    ngx_slab_page_t  *pages;        /* Page Group */    ngx_slab_page_t free   ;         /* Free Page list */    U_char           *start;        /* The starting address of the assignable space */    U_char           *end;          /* End Address of memory block */    ...                             /* Other variable members (omitted) */}ngx_slab_pool_t

Code 1 Slab Head Structure

3.2-page Management

3.2. Allocation of 1 pages

1) before assigning

After slab initialization, all pages can be viewed as a contiguous whole, with the memory structure as shown:



Figure 2 Structure of the page (before assignment)

2) apply for a page

When requesting a page, detach pages[0] from the free list, as shown in:



Figure 3 Structure of the page (Request a page)

3) apply for two pages

When applying for page two, detach page[3] and pages[4] as a whole from the free list, as shown in:



Figure 4 Structure of the page (application two pages)

3.2.2 pages of recycling

1) Recycling a page

When a page is recycled, the recycled pages are not merged with the unassigned pages, but are concatenated by the linked list, as shown in:



Figure 5 Structure of the page (recycling a page)

2) Recycling two pages

When a page is recycled, the recycled pages are not merged with the unassigned pages, but are concatenated by the linked list, as shown in:



Figure 6 Structure of the page (recycle two pages)

Management of 3.4 Slots

The function of the slot array can be described in the beginning of chapter three. Each member of a slot array is the equivalent of a linked header, which organizes the page used to allocate each size (1~1024) in the slot allocation and recycling process through a linked list. For example, at some point, the following state may exist:



Figure 7 The relationship between slots and pages

3.4.1 pages of Management

1) Initial state

After slab initialization, the next node of the slot link header is null, as shown in:



Figure 8 Slot Initial state

2) Add a page

SLOT[2] is responsible for allocating and reclaiming 32 (17~32) bytes of space, assuming that there is now a request to allocate space between 24 bytes (17~32) and therefore will be allocated from slot[2]. However, the next page of slot[2] is null in the initial state, so you need to request a page of pages[x] memory from the page management module, and then add the page to the list of slot[2], adding the following memory structure as shown:



Figure 9 Slot[2] Add a page

3) Temporary off-link list

SLOT[2] Each page has a 4k/32=128 unit, when a page is allocated 128 times, indicating that the page can allocate the allocation of units, the page will be temporarily removed from the list, in order to prevent the next request to do invalid traversal. As shown in the following:



Figure Slot[2] The first page is used out



4) Add another page

When the 17~32 byte is applied again, the subsequent list of slot[2] is empty, so you need to manage the page again to request a page pages[y] memory, and then add the page to the list of slot[2], as shown in. If the page is again assigned, 3) is processed.



Chart one slot[2] add another page

5) Re-entry linked list

When a unit in a page pages[x] is recycled for all the cells that are exhausted, there will be 1 cells in page pages[x] that can be allocated again, and the pages[x] should be re-added to the list in slot[2] so that it can be found in the next assignment from page Pages[x]. In this case, the memory organization is as follows:



Figure 12 page Pages[x] re-entry list

6) Full page recovery

When all units of page pages[x] are freed, the page will be fully reclaimed: the page will be stripped from the linked list of slot[2] and the page pages[x] will be re-added to the free list. The memory structure diagram is as follows:



Figure 13 Recycle page Pages[x]



Allocation of 3.4.2 Slots

1) in-page structure

The pages that are added to the list of slot arrays are logically divided into memory units, where each small memory unit is marked with a bitmap, 1 is occupied, and 0 is not occupied. For example, the value of the 20th bit is 1 o'clock, which means that the 20th memory unit is occupied. If the page of this slot list can be divided into 32 blocks, the logical organizational structure is as follows:



Figure page Inside structure

2) Allocation unit

If 4 memory units are requested consecutively in the page of the Slot[s] linked list, the first 4 memory units will be occupied, then the bitmap structure as shown:



Figure 15 Allocation unit

3) Release Unit

If the 3rd memory unit in the Slot[s] linked list page is released at this time, the bitmap structure is as follows:



Figure 16 Releasing the unit

Above from: http://blog.163.com/zhangjie_0303/blog/static/99082706201442134648918/

Slab allocation mechanism of nginx principle analysis