Analysis of memory management methods based on Linux

Most of the current servers are running on Linux, so as a programmer it is necessary to briefly understand how the system works. For the memory part you need to know:

Address mapping

Memory management

Absence of page fault

Let's look at some basic knowledge. In the process, the memory is divided into two parts: kernel mode and user mode. The classic proportion is as follows:

From user mode to kernel mode, it is usually implemented by system calls and interrupts. User mode memory is divided into different areas for different purposes:

Of course, the kernel state will not be used indiscriminately, so it is divided as follows:

Let's take a closer look at how this memory is managed.

address

The mapping process of addresses inside Linux is logical address -> linear address -> physical address, the physical address is the simplest: the digital signal transmitted in the address bus, and the linear address and logical address represent a conversion rule, linear The address rules are as follows:

This part is done by the MMU, which involves the main registers CR0, CR3. The logical address appears in the machine instruction, and the logical address rules are as follows:

The logical address in Linux is equal to the linear address, which means that Inter is complicated to make things complicated, and Linux simplifies laziness.

Memory management

When the system boots, it will detect the size and condition of the memory. Before building a complex structure, you need to manage the memory in a simple way. This is the bootmem, which is simply a bitmap, but there are some optimization ideas. .

How to optimize bootmem, the efficiency is not high, when you want to allocate memory, after all, it is necessary to traverse, buddy system can solve this problem: save some 2 power-size free memory fragments internally, if you want to allocate 3page, go Take one in the list of 4pages, assign 3 and then put the remaining one back. The process of memory release is just a reverse process. Use a graph to indicate:

You can see that 0, 4, 5, 6, and 7 are all in use. Then, when 1, 2 is released, will they merge?

Static inline unsigned long

__find_buddy_index(unsigned long page_idx, unsigned int order)

{

Return page_idx ^ (1 << order);// update the highest bit, 0 to 1 interchange

}

As can be seen from the above code, 0, 1 is buddy, 2, 3 is buddy, although 1, 2 are adjacent, but they are not. Memory fragmentation is the enemy of the system operation, the partner system mechanism can prevent fragmentation to some extent~~ In addition, we can get the number of free pages in each order through cat /proc/buddyinfo.

Each time the partner system allocates memory in pages (4KB), most of the data structures used when the system is running are small. It is obviously not worthwhile to allocate 4KB for a small object. Linux uses slab to solve the allocation of small objects:

At runtime, slab "wholesale" some memory to buddy, and "sells out" after processing the dicing. With the widespread use of large-scale multiprocessor systems and NUMA systems, slab has finally revealed deficiencies:

Complex queue management

Greater management data and queue storage overhead

Running a partial queue for a long time can be very long

Very complex support for NUMA

In order to solve these masters, the slub was developed: the page structure was modified to reduce the overhead of the slab management structure, and each CPU has a local active slab (kmem_cache_cpu). For small embedded systems there is a slab simulation layer slob, which is more advantageous in this system.

The problem of small memory is solved, but there is still a problem with large memory: when using the partner system to allocate 10 x 4KB of data, it will go to the 16 x 4KB free list (so the physical memory is continuous). But it's very likely that there is memory in the system, but the partner system doesn't allocate it because they are split into small pieces. Then, vmalloc is to use these pieces to piece together a large memory, which is equivalent to collecting some "strips", assembled into a finished product and "sold":

The previous memory is directly mapped, the first time I feel the existence of page management: D In addition to high-end memory, the kmap method is provided to assign a linear address to the page.

A process consists of segments of different lengths: code segments, code for dynamic libraries, global variables, and heaps, stacks, etc. that dynamically generate data. In Linux, a set of virtual address spaces is managed for each process:

After we write the code malloc, it does not immediately occupy such a large amount of physical memory, but only maintains the above virtual address space. Only when it is really needed, the physical memory is allocated. This is COW (COPY-ON-WRITE: Write-on-write technology, and the process of physical allocation is the most complicated page fault exception processing, see below!

Absence of page fault

The mapping between physical memory and physical memory is not established until the data of a virtual memory area is actually needed. If the portion of the virtual address space accessed by the process has not been associated with a page frame, the processor automatically raises a page fault exception. The information you can get when the kernel handles page fault exceptions is as follows:

Cr2: access to linear address

Err_code: When the exception occurs, it is pushed onto the stack by the control unit, indicating the cause of the exception.

Regs: the value of the register when an exception occurs

The process is as follows:

When a page fault exception occurs, it may be swapped to disk because it is not used frequently. The swap related commands are as follows:

If the memory is mmap mapped to the memory, a page fault exception will also occur when reading and writing the corresponding memory.