Re: [PATCH v2] mm/page_alloc: fix defrag_mode for non-reclaimable allocations

["Vlastimil Babka (SUSE)" <vbabka@kernel.org>]

On 5/22/26 3:05 PM, Dmitry Ilvokhin wrote:
> On Thu, May 21, 2026 at 04:59:10PM -0700, Andrew Morton wrote:
>> On Wed, 20 May 2026 12:22:28 +0000 Dmitry Ilvokhin <d@ilvokhin.com> wrote:
>>
>>> When defrag_mode is enabled, ALLOC_NOFRAGMENT is enforced to prevent
>>> migratetype fallbacks and keep pageblocks clean. The allocator relies on
>>> reclaim and compaction to free pages of the correct type before allowing
>>> fallback as a last resort.
>>>
>>> However, non-reclaimable allocations such as GFP_ATOMIC cannot invoke
>>> direct reclaim or compaction. With defrag_mode=1, these allocations hit
>>> the !can_direct_reclaim bailout in __alloc_pages_slowpath() with
>>> ALLOC_NOFRAGMENT still set, and fail without ever attempting a fallback.
>>>
>>> This causes a large number of SLUB allocation failures for
>>> skbuff_head_cache under network-heavy workloads, despite free memory
>>> being available in other migratetype freelists.
>>
>> That sounds painful.
>>
>>> Clear ALLOC_NOFRAGMENT and retry for allocations that request kswapd
>>> reclaim but cannot do direct reclaim themselves (GFP_ATOMIC).  Purely
>>> speculative allocations like GFP_TRANSHUGE_LIGHT that don't set
>>> __GFP_KSWAPD_RECLAIM are left to fail, since they have reasonable
>>> fallbacks and should not cause fragmentation.
>>
>> How serious is this to our users when running real-world workloads?
> 
> We observed it on a few of the Meta workloads that adopted
> defrag_mode=1.

Do you (or Johannes) have some observations to share about what
motivated those to adopt it, what kind of workloads benefit and how?
Because I have no idea who uses this mode and what are the expectations.

Thanks,
Vlastimil