USEFUL GFP FLAG COMBINATIONS(9)

🌸 USEFUL GFP FLAG COMBINATIONS — gfp_t(9), Kernel API Manual 🌸

ok so bestie, this is section 9 of the Kernel API Manual, and the page is literally called Useful GFP flag combinations. it's the lil cheat-sheet of the GFP combos everyone actually uses, and i'm gonna walk you through every single one 💖

✨ DESCRIPTION ✨

so here's the whole vibe: these are the useful GFP flag combinations that are commonly used — the greatest hits, the ones that ate 💅

and the rec is super clear: it is recommended that subsystems start with one of these combinations and then set/clear __GFP_FOO flags as necessary. that's it, that's the whole strategy — pick a base combo, then tweak ✨

🦋 the flags themselves

• GFP_ATOMIC — users can not sleep and the allocation needs to succeed, no cap. a lower watermark is applied so you can get access to the "atomic reserves". ⚠️ the current implementation doesn't support NMI, nor contexts that disable preemption under PREEMPT_RT — and yes that includes raw_spin_lock and plain preempt_disable. see "Memory allocation" in Documentation/core-api/real-time/differences.rst for more info. iykyk 😭
• GFP_KERNEL — the classic, the main character 👑 it's typical for kernel-internal allocations. the caller requires ZONE_NORMAL or a lower zone for direct access, but can direct reclaim.
• GFP_KERNEL_ACCOUNT — literally the same as GFP_KERNEL, except the allocation is accounted to kmemcg. that's the whole diff fr fr.
• GFP_NOWAIT — for kernel allocations that should not stall for direct reclaim, start physical IO, or use any filesystem callback. and bestie… it is very likely to fail to allocate memory, even for very small allocations 💀 the same restrictions on calling contexts apply as for GFP_ATOMIC.
• GFP_NOIO — will use direct reclaim to discard clean pages or slab pages that do not require the starting of any physical IO. 🫶 please try to avoid using this flag directly — instead use memalloc_noio_{save,restore} to mark the whole scope which cannot perform any IO, with a short explanation why. all allocation requests will inherit GFP_NOIO implicitly.
• GFP_NOFS — will use direct reclaim but will not use any filesystem interfaces. same deal, please try to avoid using this flag directly — instead use memalloc_nofs_{save,restore} to mark the whole scope which cannot/shouldn't recurse into the FS layer, with a short explanation why. all allocation requests will inherit GFP_NOFS implicitly.
• GFP_USER — for userspace allocations that also need to be directly accessibly by the kernel or hardware. typically used by hardware for buffers that are mapped to userspace (e.g. graphics) that hardware still must DMA to. 🔥 cpuset limits are enforced for these allocations.
• GFP_DMA — exists for historical reasons and should be avoided where possible 🙈 the flag indicates that the caller requires that the lowest zone be used (ZONE_DMA or 16M on x86-64). ideally this would be removed, but it would require careful auditing, because some users really require it and others use the flag to avoid lowmem reserves in ZONE_DMA and treat the lowest zone as a type of emergency reserve.
• GFP_DMA32 — similar to GFP_DMA, except the caller requires a 32-bit address. 🎀 note that kmalloc(..., GFP_DMA32) does not return DMA32 memory because the DMA32 kmalloc cache array is not implemented. (Reason: there is no such user in kernel.)
• GFP_HIGHUSER — for userspace allocations that may be mapped to userspace, do not need to be directly accessible by the kernel, but that cannot move once in use. an example may be a hardware allocation that maps data directly into userspace but has no addressing limitations.
• GFP_HIGHUSER_MOVABLE — for userspace allocations that the kernel does not need direct access to but can use kmap when access is required. they are expected to be movable via page reclaim or page migration 🦋 typically, pages on the LRU would also be allocated with GFP_HIGHUSER_MOVABLE.
• GFP_TRANSHUGE and GFP_TRANSHUGE_LIGHT — used for THP allocations. they are compound allocations that will generally fail quickly if memory is not available and will not wake kswapd/kcompactd on failure. the _LIGHT version does not attempt reclaim/compaction at all and is by default used in page fault path, while the non-light is used by khugepaged.

💀 friendly reminder that GFP_ATOMIC and GFP_NOWAIT are the risky girls — no sleeping, and GFP_NOWAIT is very likely to fail even on tiny allocations. don't say i didn't warn you 😭

🌈 SEE ALSO 🌈

• Kernel file ./tools/include/linux/gfp_types.h
• gfp_t(9)
• Page mobility and placement hints(9)
• Watermark modifiers(9)
• Reclaim modifiers(9)
• Action modifiers(9)

that's the whole page bestie, you're so ready for your allocator era 👑✨

signing off from ./tools/include/linux — October 2026 edition of Useful GFP f…combinations(9) 🎀💜