Re: [PATCH 6.6.y 3/3] mm/page_alloc: avoid direct reclaim and compaction for costly __GFP_NORETRY allocations

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] mm/page_alloc: __alloc_pages_slowpath() skips reclaim for
  defrag=always THP
--

commit 96be855a15aa5fcbbe0ed938a76cc7cd6f5771e1
Author: Salvatore Dipietro <dipiets@amazon.it>

mm/page_alloc: avoid direct reclaim and compaction for costly __GFP_NORETRY allocations

This commit clears __GFP_DIRECT_RECLAIM on slowpath entry for costly
__GFP_NORETRY allocations that do not specify __GFP_THISNODE, avoiding
direct reclaim and compaction.

Link: https://lore.kernel.org/20261001082152.2879289-1-dipiets@amazon.it
Link: https://lore.kernel.org/all/20260403193535.9970-1-dipiets@amazon.it/T/#t [v1]
Link: https://lore.kernel.org/linux-mm/20260420161404.642-1-dipiets@amazon.it/T/#u [v2]
Link: https://lore.kernel.org/all/20260710143437.12379-1-dipiets@amazon.it/T/#u [v3]
Link: https://lore.kernel.org/all/20260904115629.3993331-1-dipiets@amazon.it/T/#u [v4]
Link: https://lore.kernel.org/all/20260911142102.2294202-1-dipiets@amazon.it/T/#u [v5]

> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 8ac6556d19c13..02993879aa233 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3950,7 +3950,7 @@ static inline struct page *
>  __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
>  						struct alloc_context *ac)
>  {
> -	bool can_direct_reclaim = gfp_mask & __GFP_DIRECT_RECLAIM;
> +	bool can_direct_reclaim;
>  	bool can_compact = gfp_compaction_allowed(gfp_mask);
>  	const bool costly_order = order > PAGE_ALLOC_COSTLY_ORDER;
>  	struct page *page = NULL;
> @@ -3964,6 +3964,16 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int order,
>  	unsigned int zonelist_iter_cookie;
>  	int reserve_flags;
>  
> +	/*
> +	 * Costly __GFP_NORETRY callers have a cheap fallback, so don't stall
> +	 * them in reclaim or compaction. __GFP_THISNODE callers are exempt.
> +	 */
> +	if (costly_order && (gfp_mask & __GFP_NORETRY) &&
> +	    !(gfp_mask & __GFP_THISNODE))
> +		gfp_mask &= ~__GFP_DIRECT_RECLAIM;
> +
> +	can_direct_reclaim = gfp_mask & __GFP_DIRECT_RECLAIM;
> +
>  restart:
>  	compaction_retries = 0;
>  	no_progress_loops = 0;

[Severity: Medium]
Does clearing __GFP_DIRECT_RECLAIM here disable direct compaction and
direct reclaim for non-__GFP_THISNODE THP allocations when
transparent_hugepage/defrag is set to always?

For a VMA without MADV_HUGEPAGE under defrag=always, vma_thp_gfp_mask()
returns GFP_TRANSHUGE | __GFP_NORETRY:

mm/huge_memory.c:vma_thp_gfp_mask() {
    ...
	/* Always do synchronous compaction */
	if (test_bit(TRANSPARENT_HUGEPAGE_DEFRAG_DIRECT_FLAG, &transparent_hugepage_flags))
		return GFP_TRANSHUGE | (vma_madvised ? 0 : __GFP_NORETRY);
    ...
}

When vma_alloc_folio() retries across all allowed nodes after the local
__GFP_THISNODE attempt fails (or allocates under MPOL_INTERLEAVE or
MPOL_PREFERRED_MANY), it calls __folio_alloc() without __GFP_THISNODE:

mm/mempolicy.c:vma_alloc_folio() {
    ...
			if (!folio && (gfp & __GFP_DIRECT_RECLAIM))
				folio = __folio_alloc(gfp, order, hpage_node,
						      nmask);
    ...
}

Because HPAGE_PMD_ORDER > PAGE_ALLOC_COSTLY_ORDER,
__alloc_pages_slowpath() now clears __GFP_DIRECT_RECLAIM and skips both
__alloc_pages_direct_compact() and __alloc_pages_direct_reclaim() on
those attempts.

This also makes the async compaction priority fallback in the initial
direct compaction block unreachable dead code, since reaching
costly_order && (gfp_mask & __GFP_NORETRY) inside the can_direct_reclaim
block now requires __GFP_THISNODE to be set, so the check there always
branches to nopage:

mm/page_alloc.c:__alloc_pages_slowpath() {
    ...
		if (costly_order && (gfp_mask & __GFP_NORETRY)) {
			...
			if (gfp_mask & __GFP_THISNODE)
				goto nopage;

			compact_priority = INIT_COMPACT_PRIORITY;
		}
    ...
}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20261113110724.2920455-1-dipiets@amazon.it?part=3