From: Johannes Weiner <hannes@cmpxchg.org>
To: "Vlastimil Babka (SUSE)" <vbabka@kernel.org>
Cc: Matt Fleming <matt@readmodwrite.com>,
Salvatore Dipietro <dipiets@amazon.it>,
akpm@linux-foundation.org, abuehaze@amazon.com,
alisaidi@amazon.com, blakgeof@amazon.com, brauner@kernel.org,
brendan.jackman@linux.dev, david@redhat.com, dgc@kernel.org,
dipietro.salvatore@gmail.com, djwong@kernel.org,
hch@infradead.org, hch@lst.de, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-xfs@vger.kernel.org, mhocko@suse.com,
ritesh.list@gmail.com, rvvandan@amazon.com,
stable@vger.kernel.org, surenb@google.com, willy@infradead.org,
ziy@nvidia.com
Subject: [PATCH 1/2] mm: page_alloc: do not give all non-blocking requests reserve access
Date: Mon, 21 Sep 2026 10:38:18 -0400 [thread overview]
Message-ID: <arFBWvzXPYrKuIYi@cmpxchg.org> (raw)
In-Reply-To: <arFBJdYaRx_iJNDA@cmpxchg.org>
281dd25c1a01 ("mm/page_alloc: let GFP_ATOMIC order-0 allocs access
highatomic reserves") accidentally gave all non-blocking allocation
requests access to highatomic reserves, which includes GFP_NOWAIT and
other sites clearing __GFP_DIRECT_RECLAIM.
While this improved atomic request success rate, it's unintentionally
broad and can actually worsen highatomic requests by squandering the
reserves on requests that don't need it.
There are concurrent efforts to clear __GFP_DIRECT_RECLAIM altogether
for costly order __GFP_NORETRY requests, which would have then also
fall into this exemption and deplete reserves even faster.
What GFP_ATOMIC has over the others is __GFP_HIGH, which
alloc_flags_slowpath() translates to ALLOC_MIN_RESERVE.
Narrow the exemption to contexts that have both ALLOC_NON_BLOCK |
ALLOC_MIN_RESERVE.
Reported-by: Sashiko <sashiko-bot@kernel.org>
Fixes: 281dd25c1a01 ("mm/page_alloc: let GFP_ATOMIC order-0 allocs access highatomic reserves")
Cc: stable@vger.kernel.org
Signed-off-by: Johannes Weiner <hannes@cmpxchg.org>
---
mm/page_alloc.c | 4 +++-
mm/page_alloc.h | 3 +++
2 files changed, 6 insertions(+), 1 deletion(-)
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 12fac9084c48..7b46d0ac3a56 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -3246,7 +3246,9 @@ struct page *rmqueue_buddy(struct zone *preferred_zone, struct zone *zone,
* reserves as failing now is worse than failing a
* high-order atomic allocation in the future.
*/
- if (!page && (alloc_flags & (ALLOC_OOM|ALLOC_NON_BLOCK)))
+ if (!page &&
+ ((alloc_flags & ALLOC_OOM) ||
+ (alloc_flags & ALLOC_MASK_ATOMIC) == ALLOC_MASK_ATOMIC))
page = __rmqueue_smallest(zone, order, MIGRATE_HIGHATOMIC);
if (!page) {
diff --git a/mm/page_alloc.h b/mm/page_alloc.h
index b9259deddb59..ad89f83d1dab 100644
--- a/mm/page_alloc.h
+++ b/mm/page_alloc.h
@@ -60,6 +60,9 @@
/* Flags that allow allocations below the min watermark. */
#define ALLOC_RESERVES (ALLOC_NON_BLOCK|ALLOC_MIN_RESERVE|ALLOC_HIGHATOMIC|ALLOC_OOM)
+/* Flags that mean GFP_ATOMIC */
+#define ALLOC_MASK_ATOMIC (ALLOC_NON_BLOCK|ALLOC_MIN_RESERVE)
+
/*
* Structure for holding the mostly immutable allocation parameters passed
* between functions involved in allocations, including the alloc_pages*
--
2.55.0
next prev parent reply other threads:[~2026-09-21 14:38 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 11:56 [PATCH v4] mm/page_alloc: avoid direct compaction for costly __GFP_NORETRY allocations Salvatore Dipietro
2026-09-04 14:11 ` Vlastimil Babka (SUSE)
2026-09-04 15:08 ` Zi Yan
2026-09-07 7:30 ` Vlastimil Babka (SUSE)
2026-09-09 2:33 ` Zi Yan
2026-09-09 8:51 ` Vlastimil Babka (SUSE)
2026-09-04 16:10 ` Johannes Weiner
2026-09-06 0:42 ` Andrew Morton
2026-09-06 23:05 ` Dave Chinner
2026-09-10 11:46 ` Salvatore Dipietro
2026-09-10 22:00 ` Andrew Morton
2026-09-11 14:30 ` Salvatore Dipietro
2026-09-11 15:59 ` Johannes Weiner
2026-09-16 11:24 ` Vlastimil Babka (SUSE)
2026-09-16 15:58 ` Johannes Weiner
2026-09-16 22:34 ` Andrew Morton
2026-09-16 22:35 ` Andrew Morton
2026-09-19 4:13 ` Matthew Wilcox
2026-09-21 9:35 ` Vlastimil Babka (SUSE)
2026-09-18 7:05 ` Vlastimil Babka (SUSE)
2026-09-18 21:28 ` Andrew Morton
2026-09-22 8:44 ` Vlastimil Babka (SUSE)
2026-09-21 14:37 ` Johannes Weiner
2026-09-21 14:38 ` Johannes Weiner [this message]
2026-09-21 14:54 ` [PATCH 1/2] mm: page_alloc: do not give all non-blocking requests reserve access Matthew Wilcox
2026-09-21 15:58 ` Johannes Weiner
2026-09-21 14:39 ` [PATCH 2/2] mm: page_alloc: remove ALLOC_NON_BLOCK from ALLOC_RESERVES Johannes Weiner
2026-09-07 5:54 ` [PATCH v4] mm/page_alloc: avoid direct compaction for costly __GFP_NORETRY allocations Christoph Hellwig
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=arFBWvzXPYrKuIYi@cmpxchg.org \
--to=hannes@cmpxchg.org \
--cc=abuehaze@amazon.com \
--cc=akpm@linux-foundation.org \
--cc=alisaidi@amazon.com \
--cc=blakgeof@amazon.com \
--cc=brauner@kernel.org \
--cc=brendan.jackman@linux.dev \
--cc=david@redhat.com \
--cc=dgc@kernel.org \
--cc=dipietro.salvatore@gmail.com \
--cc=dipiets@amazon.it \
--cc=djwong@kernel.org \
--cc=hch@infradead.org \
--cc=hch@lst.de \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-xfs@vger.kernel.org \
--cc=matt@readmodwrite.com \
--cc=mhocko@suse.com \
--cc=ritesh.list@gmail.com \
--cc=rvvandan@amazon.com \
--cc=stable@vger.kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=willy@infradead.org \
--cc=ziy@nvidia.com \
/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
all inboxes | Powered by JetHome®