Can allocate memory linux

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.

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() before it can be used. Afterwards 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() .

Источник

Memory Allocation in Linux

Many assembly programmers make linux applications using only syscalls, without glibc. Altough this way is usually considered bad practice, it is a fact.

One problem that pops out when using only syscalls is lack of managed dynamic memory (heap). Linux kernel doesn’t provide any heap management. For most applications, that functionality is provided by glibc.

sys_mmap()

First option is to use sys_mmap() to allocate pages of memory. This approach has several problems.

Most apparent problem is that smallest block that can be allocated with sys_mmap() has 4KB. That is too much for most cases when allocation is needed.

Another problem is enlarging memory block. Dynamically allocated blocks sometime need to be enlarged. When enlarging block, sys_mmap() often has to move block to different place. That means all pointers to (and into) block has to be updated.

There is possibility to enlarge block without allowing system to move it, but that is very unrealiable way. It often fails and is practically unusuable.

Updating pointers may be sometimes hard, especially in assembly where using relative indexes to block wastes precious registers, and makes code a bit uglier.

These are two main reasons why sys_mmap() may not be right solution. There are also cases when sys_mmap() works fine, then it is okay to use it.

sys_brk()

Another possibility is using sys_brk() . This call is provided by kernel specifically to allow writing heap manager using it.

This call allocates memory right behind application image in memory. Memory is never moved, so you will never need to update pointers. There is plenty of memory behind image, and enlarging this block is safe.

Problem could be that you only have one such block. If you need to allocate more blocks, you need some custom memory management. Still, for applications that need only simple management, like single list of fixed-size structures, this is fine solution.

Existing heap managers

For any more complex application, neither method is good enough, and some more complex heap management is needed.

Most common way is to use glibc. This is good and easy solution.

Some assembly programmers doesn’t like using glibc. For them, there is assembly library FASMLIB, which provides heap manager too.

Unfortunately, these two libraries cannot be used together, because they both use sys_brk() to allocate memory pool.

Custom heap manager

Some people prefer writing their own heap manager.

Custom specialized memory managers usually perform better than general-purpose managers, which must provide all functionality needed. When memory management is bottleneck of application speed, one should consider writing memory manager specialized for actual task.

However, writing a good general-purpose heap manager is a very complicated task. Especially if it has to support multithreaded application (that usually isn’t case in linux, but still. ). If there is a heap manager alredy written, that does what you need, then my advice is to stick to existing one.

Links

lscr, linux syscalls reference and headers

glibc, GNU implemenentation of C�standard library, provides heap management

FASMLIB, general purpose assembly library, provides heap management

Comments

You can contact the author using e-mail vid@x86asm.net.

Revisions

(dates format correspond to ISO 8601)

Источник

Linux: Преодолеваем ошибку «Cannot allocate memory»

При ручной сборке PHP на виртуальных машинах с минимальным объёмом оперативной памяти, а это как правило VPS с ОЗУ не более 1GB, можно запросто наткнуться на нехватку последней, когда во время выполнения make ваш скрипт сборки падает с предупреждением:

 virtual memory exhausted: Cannot allocate memory 

Можно ли обойти данную проблему? Конечно, если на время сборки задействовать или расширить свап (SWAP) память. Виртуальную память, которую можно разместить в файле.

Далее рассмотрим вариант, что у нас есть VPS на котором отсутствует SWAP и нам необходимо на время задействовать дополнительные 1GB виртуальной памяти.

Шаг 1: в корне файловой системы создаём файл swapfile размером 1GB который будет выполнять роль SWAP

 dd if=/dev/zero of=/swapfile bs=1024 count=1024000 

результат выполнения команды:

 1024000+0 records in 1024000+0 records out 1048576000 bytes (1.0 GB) copied, 121.885 s, 8.6 MB/s 

Шаг 2: подготавливаем SWAP область на основе файла swapfile

результат выполнения команды:

 Setting up swapspace version 1, size = 1023996 KiB no label, UUID=faaecdac-3dc6-475d-a09f-76ae0238a60e 

Шаг 3: устанавливаем режим доступа и владельца для swapfile

 chmod 0600 /swapfile && chown root /swapfile 

Шаг 4: подключаем swapfile к виртуальной памяти (своппингу)

Шаг 4.1: проверяем успешность подключения файла к своппингу

 swapon -s --- Filename Type Size Used Priority /swapfile file 1023996 0 -3 

На этом этапе мы добавили к нашей виртуальной памяти дополнительные 1GB пространства и можем смело продолжать свою работу прерванную ошибкой «Cannot allocate memory».

Шаг N: отключаем swapfile от виртуальной памяти

P.S. При отсутствии дальнейшей необходимости в такого вида SWAP, не забываем удалить файл /swapfile.

11 марта, 2023 , 19:19
handyblogger[at]gmail.com

Источник