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
next prev parent 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