Memory management during startup of LinuxKernel

A memory-managed operating system must be supported by a good memory management system during the startup of LinuxKernel. A good memory management system is like a work of art, because we can see the perfect balance between space optimization and time optimization (both saving memory and allocating and releasing fast enough ). L... the operating system with good memory management during Linux Kernel startup must be supported by a good memory management system. A good memory management system is like a work of art, because we can see the perfect balance between space optimization and time optimization (both saving memory and allocating and releasing fast enough ). Linux provides us with such an example. we can find many kernel books about its memory management. But how does the system work before it is established? When the system starts, the memory allocation goes through several stages (based on kernel 2.6.29): 1. static allocation (if so ...) 2. e820 Table 3. bootmem allocator4. zone allocator (buddy system) 5. slab allocator6. virtual space allocation, such as using vmalloc and mmap functions, of course, the time limits of the above stages are not always obvious and sometimes coexist. The following are several key points in the initialization code: start_kernel () setup_arch () setup_memory_map () // read the e820 table information from boot_params.e820_map, and then you can use find_e820_area () to allocate it. Init_memory_mapping () kernel_physical_mapping_init () // map the low mem part of the kernel page table in the virtual space. when creating a page table, the memory needs to be allocated through find_e820_area (). Initmem_init () setup_bootmem_allocator () // initialize bootmem allocator and bootmem allocator. Early_res_to_bootmem () // reserve the previously static distribution or the region allocated through find_e820_area. Paging_init () // initialize the persistent kernel ING and temporary kernel mapping sections in the high mem of the kernel page table. then, you can use kmap () or kmap_atomic () maps physical pages to the high mem area. Zone_sizes_init () // initialize zone allocator, but it is only initialized and cannot be allocated because all freelist is left empty. Vmalloc_init () // initialize the structure required to assign noncontiguous memory area. Vmalloc can allocate virtual space from VMALLOC_START to VMALLOC_END in high mem. In addition to the two types mentioned in paging_init (), the three ing modes for the high mem of the kernel are complete. This function allocates the memory needed by bootmem allocator. Mem_init () // Complete zone allocator, that is, buddy system initialization. then alloc_page () can be used. Here, the unallocated space in bootmem allocator is transferred to zone allocator, and bootmem allocator is disabled. Kmem_cache_init () // initialize slab allocator. It is a layer enhancement on zone allocator, which makes up for some inherent limitations of zone allocator. for example, it can only allocate physical pages with the power of 2. Kmalloc () will be allocated from slab allocator, and slab allocator will be allocated from zone allocator if the cache in slab allocator is insufficient. Some data at the beginning of the system startup is statically allocated, such as the code segment and data segment of the kernel, because no distributor exists yet. These are all stored by loader in a fixed physical address, and mapped to a fixed virtual address by the temporary page table. E280 table and find_e820_area () can be called allocator, although it is very simple. In the early stage of system startup, in the detect_memory () function, the system reads physical memory information from the BIOS through 15 hours of interruption and places it in boot_params (that is, zeropage ). The set_memory_map () function then reads the information into the e820 struct, and then the find_e820_area () function can allocate memory from it. The allocation method uses a simple linear query and records the allocated space to the early_res structure through reserve_early, this information will be used to set the allocated physical memory areas during bootmem allocator initialization. For example, when the system wants to create a kernel page table, it needs to apply for the memory occupied by the page table, so it calls one_page_table_init (). It finds that bootmem allocator is not available, so it calls alloc_low_page (), this function will get the memory in the [table_start, start_end] region, and this memory is applied through find_e820_area () in find_early_table_space. After the kernel page table is created, reserve_early () is called. it records the [table_start, table_end] area with "PGTABLE" as the label. Next, bootmem allocator, which is directly allocated with e820, is also an intermediate transitional product. Bootmem allocator, as its name implies, is a temporary memory distributor used during system startup. It is disabled after zone allocator is set up, and the idle zone is recycled to zone allocator. Bootmem allocator is a bitmap-based distributor, which is fast. Use the alloc_bootmem () function to allocate from bootmem allocator (). Then zone allocator. We know that the typical system has three zones: ZONE_DMA, ZONE_NORMAL, ZONE_HIGHMEM. The system creates a familiar buddy system for each zone. To put it simply, buddy system hangs the physical memory area on zone-> free_area according to the npower of 2 (n is called order. Split them during allocation until they meet the allocation application requirements and merge them when released. The alloc_page () and free_page () functions are used for allocating and releasing from zone allocator (). Buddy system is very efficient, but it brings about internal fragmentation problems, because it can only allocate pages from 0 to 2 to the MAX_ORDER power of 2, and it is not conducive to the use of hardware cache. In the kernel, fixed memory sizes such as process descriptor and open file object are frequently applied. If you apply from buddy system every time, both time and space are required. For the sake of space and time efficiency, slab allocator is available. Slab allocator is equivalent to caching memory resources in each fixed size and placing them in the cache. The system directly obtains the data from the cache when it wants to release the data. The data is not actually released, but is put back into the cache. Slab allocator maintains many caches. each cache contains the same type of boject. The cache is divided into slab. slab usually contains several physical pages of connections, which are stored in allocated or idle objects. For memory resources in slab allocator, call kmalloc () or directly call kmem_cache_alloc () for allocation, call kfree () or directly call kmem_cache_free () for release. When kmem_cache_alloc () is called and no object exists in the cache, cache_grow () is called to add slab in the cache. this is also the creation process of slab. Cache_grow () then calls kmem_getpages () to allocate physical memory to the object. Kmem_getpages will be allocated to the buddy system (kmem_getpages () => alloc_pages_node () => _ alloc_pages ()). Therefore, we can say that slab allocator is not a substitute for buddy system, but is enhanced. Then, the system's memory management system was initially established. There are two types of memory resources in the system: virtual space and physical space. In the kernel state, vmalloc () is used to apply for a virtual space, and alloc_page () is also called to apply for a physical space, and then mapped to the virtual space. However, kmalloc can directly apply for physical space from slab allocator, and allocate it to buddy system if the memory in slab allocator is insufficient. In this way, the physical space applied for has no explicit ing in the virtual address space. of course, if it is a low mem part, it has been mapped to PAGE_OFFSET during system initialization. In the user state, if the app calls a function such as malloc, malloc will call mmap, and mmap will apply to call the virtual space of the process, where there is no corresponding physical page. Only page fault occurs during real access. physical pages are allocated from buddy system in pagefault handler.