Memory allocated in linux

Process Memory Management in Linux

Process memory management is a crucial aspect of any operating system. In Linux, memory management system is designed to efficiently manage memory usage, allowing processes to access and use memory they require while preventing them from accessing memory they do not own. In this article, we will discuss process memory management in Linux in detail, covering various aspects such as memory allocation, virtual memory, memory mapping, and more.

Memory Allocation

Memory allocation is process of assigning memory to a process or program. In Linux, kernel provides two main methods for memory allocation: static and dynamic.

Static Memory Allocation

Static memory allocation is done at compile-time, where memory allocation for a program is fixed and cannot be changed during runtime. memory is allocated in program’s data section or stack segment. data section contains global variables and static variables, while stack segment contains local variables.

Dynamic Memory Allocation

Dynamic memory allocation is done during runtime, where memory allocation for a program can be dynamically adjusted based on program’s requirements. kernel provides various system calls such as malloc(), calloc(), and realloc() to dynamically allocate memory. These functions allocate memory from heap segment of program’s address space.

Virtual Memory

Virtual memory is a memory management technique that allows a program to use more memory than is physically available in system. In Linux, virtual memory is implemented using a combination of hardware and software. hardware component is Memory Management Unit (MMU), which is responsible for translating virtual memory addresses to physical memory addresses. software component is kernel’s Virtual Memory Manager (VMM), which manages allocation and deallocation of virtual memory.

Memory Mapping

Memory mapping is a technique that allows a process to access a file’s contents as if it were part of process’s memory. In Linux, memory mapping is implemented using mmap() system call. mmap() system call maps a file into a process’s virtual memory address space, allowing process to read and write to file’s contents as if it were part of its own memory. Memory mapping is commonly used in applications such as databases and multimedia players, where large files need to be accessed efficiently.

Shared Memory

Shared memory is a technique that allows multiple processes to access same portion of memory. In Linux, shared memory is implemented using shmget(), shmat(), and shmdt() system calls. shmget() system call creates a shared memory segment, shmat() attaches shared memory segment to a process’s address space, and shmdt() detaches shared memory segment from process’s address space. Shared memory is commonly used in inter-process communication, where multiple processes need to share data efficiently.

Swapping

Swapping is a technique that allows kernel to move pages of memory from RAM to a swap space on disk when system’s memory is low. In Linux, swapping is implemented using a combination of hardware and software. hardware component is disk, which is used as swap space. software component is kernel’s Swapping Manager, which manages swapping process. When system’s memory is low, Swapping Manager selects pages of memory to swap out to disk, freeing up memory for other processes.

Some additional concepts to consider include −

Kernel Memory Management

The Linux kernel itself also requires memory management, and it uses a separate set of memory management techniques to manage kernel memory. Kernel memory is used to store data structures and code required by kernel to operate. kernel uses techniques like memory mapping, page caching, and memory allocation to manage kernel memory.

Memory Protection

Memory protection is another critical aspect of memory management in Linux. Memory protection techniques prevent processes from accessing memory they are not authorized to access. MMU implements memory protection by using page tables, which map virtual memory addresses to physical memory addresses and track permissions for each memory page.

Memory Fragmentation

Memory fragmentation occurs when available memory is divided into small, non-contiguous chunks, making it difficult to allocate larger blocks of memory. Memory fragmentation can lead to performance issues and even crashes if system runs out of memory. Linux kernel uses several techniques to manage memory fragmentation, including memory compaction and defragmentation.

Memory Leak Detection

As mentioned earlier, failing to release dynamically allocated memory can result in memory leaks, where memory is not returned to system and can eventually cause program to crash due to insufficient memory. Detecting and fixing memory leaks is crucial for maintaining system stability and performance. Linux provides several tools for detecting memory leaks, including valgrind, which can detect memory leaks and other memory-related issues.

Conclusion

In conclusion, process memory management is a crucial aspect of any operating system, and Linux is no exception. Linux kernel provides a robust and efficient memory management system, allowing processes to access and use memory they require while preventing them from accessing memory they do not own. In this article, we discussed various aspects of process memory management in Linux, including memory allocation, virtual memory, memory mapping, shared memory, and swapping. Understanding these concepts is essential for any Linux developer or administrator to efficiently manage memory usage in their systems.

Источник

Memory Allocation Guide¶

Linux provides a variety of APIs for memory allocation. You can allocate small chunks using kmalloc or kmem_cache_alloc families, large virtually contiguous areas using vmalloc and its derivatives, or you can directly request pages from the page allocator with alloc_pages . It is also possible to use more specialized allocators, for instance cma_alloc or zs_malloc .

Most of the memory allocation APIs use GFP flags to express how that memory should be allocated. The GFP acronym stands for “get free pages”, the underlying memory allocation function.

Diversity of the allocation APIs combined with the numerous GFP flags makes the question “How should I allocate memory?” not that easy to answer, although very likely you should use

Of course there are cases when other allocation APIs and different GFP flags must be used.

Get Free Page flags¶

The GFP flags control the allocators behavior. They tell what memory zones can be used, how hard the allocator should try to find free memory, whether the memory can be accessed by the userspace etc. The Documentation/core-api/mm-api.rst provides reference documentation for the GFP flags and their combinations and here we briefly outline their recommended usage:

• Most of the time GFP_KERNEL is what you need. Memory for the kernel data structures, DMAable memory, inode cache, all these and many other allocations types can use GFP_KERNEL . Note, that using GFP_KERNEL implies GFP_RECLAIM , which means that direct reclaim may be triggered under memory pressure; the calling context must be allowed to sleep.
• If the allocation is performed from an atomic context, e.g interrupt handler, use GFP_NOWAIT . This flag prevents direct reclaim and IO or filesystem operations. Consequently, under memory pressure GFP_NOWAIT allocation is likely to fail. Allocations which have a reasonable fallback should be using GFP_NOWARN .
• If you think that accessing memory reserves is justified and the kernel will be stressed unless allocation succeeds, you may use GFP_ATOMIC .
• Untrusted allocations triggered from userspace should be a subject of kmem accounting and must have __GFP_ACCOUNT bit set. There is the handy GFP_KERNEL_ACCOUNT shortcut for GFP_KERNEL allocations that should be accounted.
• Userspace allocations should use either of the GFP_USER , GFP_HIGHUSER or GFP_HIGHUSER_MOVABLE flags. The longer the flag name the less restrictive it is. GFP_HIGHUSER_MOVABLE does not require that allocated memory will be directly accessible by the kernel and implies that the data is movable. GFP_HIGHUSER means that the allocated memory is not movable, but it is not required to be directly accessible by the kernel. An example may be a hardware allocation that maps data directly into userspace but has no addressing limitations. GFP_USER means that the allocated memory is not movable and it must be directly accessible by the kernel.

You may notice that quite a few allocations in the existing code specify GFP_NOIO or GFP_NOFS . Historically, they were used to prevent recursion deadlocks caused by direct memory reclaim calling back into the FS or IO paths and blocking on already held resources. Since 4.12 the preferred way to address this issue is to use new scope APIs described in Documentation/core-api/gfp_mask-from-fs-io.rst .

Other legacy GFP flags are GFP_DMA and GFP_DMA32 . They are used to ensure that the allocated memory is accessible by hardware with limited addressing capabilities. So unless you are writing a driver for a device with such restrictions, avoid using these flags. And even with hardware with restrictions it is preferable to use dma_alloc* APIs.

Selecting memory allocator¶

The most straightforward way to allocate memory is to use a function from the kmalloc() family. And, to be on the safe size it’s best to use routines that set memory to zero, like kzalloc() . If you need to allocate memory for an array, there are kmalloc_array() and kcalloc() helpers.

The maximal size of a chunk that can be allocated with kmalloc is limited. The actual limit depends on the hardware and the kernel configuration, but it is a good practice to use kmalloc for objects smaller than page size.

The address of a chunk allocated with kmalloc is aligned to at least ARCH_KMALLOC_MINALIGN bytes. For sizes which are a power of two, the alignment is also guaranteed to be at least the respective size.

For large allocations you can use vmalloc() and vzalloc() , or directly request pages from the page allocator. The memory allocated by vmalloc and related functions is not physically contiguous.

If you are not sure whether the allocation size is too large for kmalloc , it is possible to use kvmalloc() and its derivatives. It will try to allocate memory with kmalloc and if the allocation fails it will be retried with vmalloc . There are restrictions on which GFP flags can be used with kvmalloc ; please see kvmalloc_node() reference documentation. Note that kvmalloc may return memory that is not physically contiguous.

If you need to allocate many identical objects you can use the slab cache allocator. The cache should be set up with kmem_cache_create() or kmem_cache_create_usercopy() before it can be used. The second function should be used if a part of the cache might be copied to the userspace. After the cache is created kmem_cache_alloc() and its convenience wrappers can allocate memory from that cache.

When the allocated memory is no longer needed it must be freed. You can use kvfree() for the memory allocated with kmalloc , vmalloc and kvmalloc . The slab caches should be freed with kmem_cache_free() . And don’t forget to destroy the cache with kmem_cache_destroy() .

© Copyright The kernel development community

Источник