RECLAIM MODIFIERS(9)

💅 Reclaim modifiers 💅

ok so this is a page from the Kernel API Manual, section 9, and it's literally all about the reclaim modifiers — the flags that control how the allocator goes feral trying to get you memory. bestie, pay attention, because the fine print here is everything. 🎀

⚠️ Huge disclaimer first: all of the following flags are only applicable to sleepable allocations. Like, GFP_NOWAIT and GFP_ATOMIC will straight up ignore them. no cap, they don't care. 💀

---

✨ The flags themselves ✨

• __GFP_IO — green light to start physical IO. she's allowed to go touch the disk. 🦋
• __GFP_FS — lets the allocator call down to the low-level FS. clearing this flag keeps the allocator from recursing into the filesystem, which might already be holding locks. so like, if you're already inside the FS with locks in hand, don't do that to yourself. 🙈
• __GFP_DIRECT_RECLAIM — says the caller may enter direct reclaim. you can clear this flag to dodge unnecessary delays when a fallback option is available. lowkey a vibe-saver. ⭐
• __GFP_KSWAPD_RECLAIM — the caller wants to wake kswapd when the low watermark is reached, and have it reclaim pages until the high watermark is hit. a caller may want to clear this flag when fallback options are available and the reclaim is likely to disrupt the system. the canonical example is THP allocation, where a fallback is cheap but reclaim/compaction may cause indirect stalls. 😭
• __GFP_RECLAIM — shorthand to allow/forbid both direct and kswapd reclaim. two-for-one, iconic. 👑

---

🧚 the default behavior tea 🧚

k so the default allocator behavior depends on the request size. we have this concept of so-called costly allocations (with order > PAGE_ALLOC_COSTLY_ORDER).

!costly allocations are too essential to fail, so they're implicitly non-failing by default — with some exceptions, like OOM victims might fail, so the caller still has to check for failures. meanwhile costly requests try to be not disruptive and back off even without invoking the OOM killer. 🌸

the following three modifiers can be used to override some of these implicit rules. and yes, please note: all of them must be used along with the __GFP_DIRECT_RECLAIM flag. all three. every time. periodt. 💅

🌈 __GFP_NORETRY

the VM implementation will try only very lightweight memory direct reclaim to get some memory under memory pressure (so yes, it can sleep). it will avoid disruptive actions like the OOM killer. the caller must handle the failure, which is quite likely to happen under heavy memory pressure. this flag is suitable when failure can easily be handled at small cost — like reduced throughput. ngl, she's the "no thoughts, head empty" option and that's the point. 🍓

🔥 __GFP_RETRY_MAYFAIL

the VM implementation will retry memory reclaim procedures that have previously failed if there's some indication that progress has been made elsewhere. it can wait for other tasks to attempt high-level approaches to freeing memory, such as compaction (which removes fragmentation) and page-out. there's still a definite limit to the number of retries, but it's a larger limit than with __GFP_NORETRY.

allocations with this flag may fail — but only when there is genuinely little unused memory. while these allocations don't directly trigger the OOM killer, their failure indicates the system is likely to need the OOM killer soon. 👀 the caller must handle failure, but can reasonably do so by failing a higher-level request, or completing it only in a much less efficient manner. and if the allocation does fail, and the caller is in a position to free some non-essential memory, doing so could benefit the system as a whole. main character energy: thinking about the whole system. 🫶

💀 __GFP_NOFAIL

ok this one is intense. the VM implementation _must_ retry infinitely — the caller cannot handle allocation failures. the allocation could block indefinitely but will never return with failure. testing for failure is pointless.

• it _must_ be blockable and used together with __GFP_DIRECT_RECLAIM
• it should _never_ be used in non-sleepable contexts
• new users should be evaluated carefully (and the flag should be used only when there is no reasonable failure policy)
• but it is definitely preferable to use the flag rather than opencode an endless loop around the allocator

🚨 one more limit: allocating pages from the buddy with __GFP_NOFAIL and order > 1 is not supported. please consider using kvmalloc instead. that's the move. 🙏

---

🌟 SEE ALSO 🌟

so you can go down the rabbit hole, here's the whole squad:

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

---

and that's the page!! 🎀 from ./tools/include/linux, October 2026 — go forth and reclaim responsibly, bestie. mwah. 💖✨🦋