Shulou(Shulou.com)05/31 Report--

The main content of this article is to explain "what the Linux memory application is like". Interested friends may wish to take a look. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn what the Linux memory application is like.

Based on the above, the following figure is the memory mapping model of Linux

Each process has its own process space. 0-3G of the process space is the user space and 3G-4G is the kernel space.

The user space of each process is not on the same physical memory page, but the kernel space of all processes corresponds to the same physical address.

The address allocated by vmalloc can be either high-end memory or low-end memory

The physical address of 0-896MB is linearly mapped to the physical mapping area.

Dynamic memory request

Like the application layer, kernel programs need to allocate memory dynamically. The difference is that kernel processes can control whether the allocated memory is in user space or kernel space. The former can be used to allocate memory to the heap area of user space. Eg, the malloc of user space of user processes will eventually call back the memory allocation function of kernel space through system calls. At this time, the memory allocation function belongs to the user process. You can allocate space in the heap area of the user process and return it, resulting in a user process getting memory allocation in its own user space. The latter is only allocated in the kernel space, so the user process cannot access the space directly, so it is mostly used to meet the memory requirements of the kernel program itself. Here is the API commonly used for Linux kernel space application memory:

Kmalloc-kfree

The memory of kmalloc applications is contiguous in physical memory, and they have only a fixed offset from the real physical address, so there is a simple translation relationship. This API is mostly used to request less than a page size of memory. The underlying layer of kmalloc needs to call _ _ get_free_pages. Gtp_t flags, which indicates the memory type in the parameter, is the abbreviation of this function. Several commonly used memory types are GFP_USER,GFP_KERNEL,GFP_ATOMIC.

GFP_USER indicates that memory is allocated for user-space pages, which can block

GFP_KERNEL is the most commonly used flag. Note that when using this flag to apply for memory, if it is not satisfied for the time being, it will cause process blocking. So, do not use GFP in non-process contexts such as interrupt handlers, tasklet and kernel timers!

GFP_ATOMIC can be used in the above three scenarios, and this flag means that if the requested memory is not available, it will be returned immediately.

/ * * kmalloc-allocate memory * @ size: how many bytes of memory are required. * @ flags: the type of memory to allocate. * The @ flags argument may be one of: *% GFP_USER-Allocate memory on behalf of user. May sleep. *% GFP_KERNEL-Allocate normal kernel ram. May sleep. *% GFP_ATOMIC-Allocation will not sleep. May use emergency pools. * For example, use this inside interrupt handlers. * / void * kmalloc (size_t size, gfp_t flags); / * * kfree-free previously allocated memory * @ objp: pointer returned by kmalloc. * If @ objp is NULL, no operation is performed. * / void kfree (const void * objp)

The same series of API and

Void * kzalloc (size_t size, gfp_t flags)

_ _ get_free_pages-free_pages

_ _ get_free_pages () is physically continuous memory like kmalloc (). This series of functions are used to obtain free memory in the Linux kernel. Because the underlying buddy algorithms manage memory in (2 ^ n) × PAGE_SIZE, they always allocate memory on a page-by-page basis.

Unsigned long _ get_free_pages (gfp_t gfp_mask, unsigned int order) void free_pages (unsigned long addr, unsigned int order)

The same series of API and

Unsigned long _ get_free_page (gfp_t gfp) unsigned long get_zeroed_page (gfp_t gfp_mask) struct page * alloc_pages (gfp_t gfp_mask, unsigned int order) void free_page (unsigned long addr)

Vmalloc-vfree

Vmalloc gives a continuous memory area in virtual memory space. In essence, this continuous virtual memory is not necessarily continuous in physical memory, so there is no simple conversion relationship between virtual memory and physical memory applied by vmalloc. For this reason, vmalloc () is usually used to allocate memory space much larger than _ _ get_free_pages (), and its implementation requires the establishment of a new page table. In addition, kmalloc,so that uses GFP_KERN will be called. Be sure not to use vmalloc in non-process contexts such as interrupt handlers, tasklet, and kernel timers!

/ * vmalloc-allocate virtually contiguous memory * @ size: allocation size * Allocate enough pages to cover @ size from the page level allocator and map them into contiguous kernel virtual space. * / void * vmalloc (unsigned long size) / * * vfree-release memory allocated by vmalloc () * @ addr: memory base address * / void vfree (const void * addr)

There are API in the same series.

/ * * vmalloc_32-allocate virtually contiguous memory (32bit addressable) * @ size: allocation size * Allocate enough 32bit PA addressable pages to cover @ size from the page level allocator and map them into contiguous kernel virtual space. * / void * vmalloc_32 (unsigned long size)

Slab caching

We know that pages are the basic unit of memory mapping, but many frequently created objects in the kernel require less than one page of memory. If you still follow the way of page mapping, frequent allocation and release will result in a waste of resources and reduce system performance. In order to solve this problem, the kernel introduces the slab mechanism, so that objects are allocated in the same memory or the same kind of memory space when they are used twice, and the basic data structure is retained, which can greatly improve the efficiency. The underlying layer of kmalloc uses the slab algorithm to manage allocated memory. Note that slab is still mapped on a page-by-page basis, but after mapping, the pages are split into the same smaller units, saving memory. The unit allocated by slab cannot be less than 32B or greater than 128K.

/ * kmem_cache_create-create the slab cache object * @ name:slab cache name, * @ size:slab size of each unit of the allocated cache * @ align: the alignment of the cache memory, generally give 0 * @ flags: control the allocated bitmask, *% SLAB_POISON-Poison the slab with a known test pattern (a5a5a5a5) to catch references to uninitialised memory. *% SLAB_RED_ZONE-Insert `Red' zones around the allocated memory to check for buffer overruns. *% SLAB_HWCACHE_ALIGN-Align the objects in this cache to a hardware cacheline. This can be beneficial if you're counting cycles as closely as davem. *% SLAB_CACHE_DMA-Use GFP_DMA memory *% SLAB_STORE_USER-Store the last owner for bug hunting * define SLAB_PANIC-Panic if kmem_cache_create () fails * / struct kmem_cache * kmem_cache_create (const char * name, size_t size, size_t align,unsigned long flags, void (* ctor) (void *)) / * * kmem_cache_alloc-Allocate an object from this cache * @ cachep: The cache to allocate from. * @ flags: See kmalloc (). * The flags are only relevant if the cache has no available objects. * / void * kmem_cache_alloc (struct kmem_cache * cachep, gfp_t flags) / * * kmem_cache_free-Deallocate an object * @ cachep: The cache the allocation was from. * @ objp: The previously allocated object. * Free an object which was previously allocated from this cache. * / void kmem_cache_free (struct kmem_cache * cachep, void * objp) void kmem_cache_destroy (struct kmem_cache * s)

Example

/ / create slab object struct kmem_cache_t * xj_sbcache; xj_sbcache = kmem_cache_create ("xjslab", sizeof (struct xj_unit_t), 0Med slabbing cache struct xj_unit_t | SLAB_PANIC,NULL,NULL); / / assign slab cache struct xj_unit_t * xj_unit; xj_unit = kmem_cache_alloc (xj_sbcache,GFP_KERNEL) / * use slab cache * / / * release slab cache * / kmem_cache_free (xj_sbcache, xj_unit); / * destroy slab cache * / kmem_cache_destroy (xj_sbcache)

Memory pool

In addition to the slab mechanism, the kernel also provides a traditional memory pool mechanism to manage the allocation of small chunks of memory. A memory pool is mainly used to solve possible memory shortages, because a memory pool has already been allocated when it is created. When we apply for memory from a memory pool that has already been created with mempool_alloc, the function will first try to call back the memory allocation function when the memory pool is created. If there is no memory to allocate, it will use the memory allocated in advance when the memory pool is created. In this way, you can avoid falling into hibernation due to no memory allocation, and of course, if the pre-allocated memory has been used up, you will still fall into hibernation. The purpose of slab mechanism is to improve memory utilization and memory management efficiency, and the purpose of memory pool is to avoid memory allocation failure. The following is the API about memory pools provided in the kernel

/ * * mempool_create-create a memory pool * @ min_nr: the minimum number of elements guaranteed to be allocated for this pool. * @ alloc_fn: user-defined element-allocation function. * @ free_fn: user-defined element-freeing function. * @ pool_data: optional private data available to the user-defined functions. * this function creates and allocates a guaranteed size, preallocated memory pool. The pool can be used from the mempool_alloc () and mempool_free () functions. * This function might sleep. Both the alloc_fn () and the free_fn () functions might sleep-as long as the mempool_alloc () function is not called from IRQ contexts. * / mempool_t * mempool_create (int min_nr, mempool_alloc_t * alloc_fn, mempool_free_t * free_fn, void * pool_data) / * * mempool_alloc-allocate an element from a specific memory pool * @ pool:pointer to the memory pool which was allocated via mempool_create (). * @ gfp_mask: the usual allocation bitmask. * this function only sleeps if the alloc_fn () function sleeps or returns NULL. Note that due to preallocation, this function never* fails when called from process contexts. (it might fail if called from an IRQ context.) * / void * mempool_alloc (mempool_t * pool, gfp_t gfp_mask) / * * mempool_free-return an element to the pool. * @ element: pool element pointer. * @ pool:pointer to the memory pool which was allocated via mempool_create (). * * this function only sleeps if the free_fn () function sleeps. * / void mempool_free (void * element, mempool_t * pool) / * * mempool_destroy-deallocate a memory pool * @ pool:pointer to the memory pool which was allocated via mempool_create () * * Free all reserved elements in @ pool and @ pool itself. This function only sleeps if the free_fn () function sleeps. * / void mempool_destroy (mempool_t * pool) at this point, I believe you have a better understanding of "what the Linux memory request is like". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.