Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: sashiko-bot@kernel.org
To: "Salvatore Dipietro" <dipiets@amazon.it>
Cc: dipietro.salvatore@gmail.com,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"Vlastimil Babka" <vbabka@kernel.org>,
	"Johannes Weiner" <hannes@cmpxchg.org>,
	linux-mm@kvack.org
Subject: Re: [PATCH 6.12.y 3/3] mm/page_alloc: avoid direct reclaim and compaction for costly __GFP_NORETRY allocations
Date: Sat, 14 Nov 2026 11:07:03 +0000	[thread overview]
Message-ID: <sashiko-outbox-214389@kernel.org> (raw)
In-Reply-To: <20261113110611.2915381-4-dipiets@amazon.it>

Thank you for your contribution! Sashiko AI review found 1 potential
issue to consider:
- [Medium] mm: __alloc_pages_slowpath() breaks THP/mTHP defrag=always
  and leaves dead code
--

commit 1bb1bbad99e28f7629c28b25e5ea8f978d0cf1c0
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 at the start of
__alloc_pages_slowpath() for costly-order __GFP_NORETRY allocations that
do not specify __GFP_THISNODE.

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 44578e149a54d..75e67f7ff4b06 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -4288,7 +4288,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);
>  	bool nofail = gfp_mask & __GFP_NOFAIL;
>  	const bool costly_order = order > PAGE_ALLOC_COSTLY_ORDER;
> @@ -4303,6 +4303,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;

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

For non-madvised VMAs under defrag=always, vma_thp_gfp_mask() returns
GFP_TRANSHUGE | __GFP_NORETRY (which includes __GFP_DIRECT_RECLAIM, omits
__GFP_KSWAPD_RECLAIM, and does not set __GFP_THISNODE):

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);
	...
}

In alloc_pages_mpol_noprof(), __GFP_THISNODE is only added for the first
local-node attempt at order == HPAGE_PMD_ORDER.  When that local attempt
fails and falls through to __alloc_pages_noprof() across all nodes, or when
alloc_anon_folio(), alloc_swap_folio(), or shmem_alloc_and_add_folio()
allocate costly mTHP orders (< HPAGE_PMD_ORDER), __GFP_THISNODE is not set.
Stripping __GFP_DIRECT_RECLAIM causes those allocations to skip direct
compaction, direct reclaim, and kswapd/kcompactd wakeups.

This also leaves the post-compaction fallback in __alloc_pages_slowpath()
unreachable, because reaching the costly_order && (gfp_mask & __GFP_NORETRY)
block inside if (can_direct_reclaim && can_compact && ...) now guarantees
that gfp_mask & __GFP_THISNODE is set:

mm/page_alloc.c:__alloc_pages_slowpath() {
		...
		if (costly_order && (gfp_mask & __GFP_NORETRY)) {
			if (compact_result == COMPACT_SKIPPED ||
			    compact_result == COMPACT_DEFERRED)
				goto nopage;
			...
			if (gfp_mask & __GFP_THISNODE)
				goto nopage;

			compact_priority = INIT_COMPACT_PRIORITY;
		}
}

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


  reply	other threads:[~2026-11-14 11:07 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-11-13 11:06 [PATCH 6.12.y 0/3] mm/page_alloc: fix iomap buffered write regression from 5d8edfb900d5 Salvatore Dipietro
2026-11-13 11:06 ` [PATCH 6.12.y 1/3] mm: page_alloc: do not give all non-blocking requests reserve access Salvatore Dipietro
2026-11-13 11:06 ` [PATCH 6.12.y 2/3] mm: page_alloc: remove ALLOC_NON_BLOCK from ALLOC_RESERVES Salvatore Dipietro
2026-11-13 11:06 ` [PATCH 6.12.y 3/3] mm/page_alloc: avoid direct reclaim and compaction for costly __GFP_NORETRY allocations Salvatore Dipietro
2026-11-14 11:07   ` sashiko-bot [this message]
2026-11-13 19:09 ` [PATCH 6.12.y 0/3] mm/page_alloc: fix iomap buffered write regression from 5d8edfb900d5 Sasha Levin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=sashiko-outbox-214389@kernel.org \
    --to=sashiko-bot@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=dipietro.salvatore@gmail.com \
    --cc=dipiets@amazon.it \
    --cc=hannes@cmpxchg.org \
    --cc=linux-mm@kvack.org \
    --cc=sashiko-reviews@lists.linux.dev \
    --cc=vbabka@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox