From: Salvatore Dipietro <dipiets@amazon.it>
To: <vbabka@kernel.org>, <akpm@linux-foundation.org>, <willy@infradead.org>
Cc: <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>, <dipiets@amazon.it>,
<djwong@kernel.org>, <hannes@cmpxchg.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>, <ziy@nvidia.com>
Subject: Re: [PATCH v4] mm/page_alloc: avoid direct compaction for costly __GFP_NORETRY allocations
Date: Wed, 23 Sep 2026 09:25:12 +0000 [thread overview]
Message-ID: <20260923092512.101833-1-dipiets@amazon.it> (raw)
In-Reply-To: <6c94405a-48e4-4842-a096-e2fbbbaa862f@kernel.org>
On 9/19/26 06:13, Matthew Wilcox wrote:
> This patch is still piling hack on hack. We haven't made a serious
> effort to understand what's going on, we're just adjusting flags until
> things stop sucking.
I have tested two new kernel patches on v7.3-rc1, each isolating one behaviour
(diffs at the bottom), and ran the same pgbench simple-update workload
(1024 clients / 96 threads / 1200s, 3 iterations each). Baseline is the
unpatched regressed kernel; target is ~135k, the pre-5d8edfb900d5 number.
Config Avg TPS % vs baseline
v7.3-rc1 baseline (no patch) 59,408 -
(a) post-reclaim drain step skipped 70,615 +18.9%
(b) compaction disabled only 107,210 +80.5%
(c) v4 (full non-blocking, reference) 154,835 +160.6%
We can notice that:
1. The drain_all_pages() IPI is not the driver. (a) skips the whole
post-reclaim drain step for costly __GFP_NORETRY -- that is
unreserve_highatomic_pageblock(), drain_all_pages() and the retry
together -- and the entire step is worth only ~11k of the ~96k gap.
Whatever the split between the three, the cross-CPU drain cannot
account for the bulk of it.
2. Turning compaction off is not enough. Your gfp_compaction_allowed()
one-liner (b) gets about half the gap, and it declines across
iterations (135k -> 98k -> 89k). It drops compaction for
__GFP_NORETRY at every order that can use it, __GFP_THISNODE
excepted, not only at the costly order v4 gates on; the decline is
consistent with the zone no longer being repaired. (c) only makes
the costly attempt non-blocking and leaves kswapd/kcompactd working,
and it does not show the decline.
3. We have collected metrics to understand how often the
allocator stalls and normalised to a million page writebacks (nr_written),
over the same 3 x 1200s iterations as above:
compact_ allocstall_ pgscan_
stall movable direct
v7.3-rc1 baseline 513 277 90,230
(a) post-reclaim drain skipped 912 472 129,249
(b) compaction disabled 0 778 44,737
(c) v4 (full non-blocking) 5 39 4,407
The baseline enters stall compaction ~100x more often per page written
than (c) does. (a) makes all three metrics worse. (b) removes direct
compaction entirely (0 stalls) but does not remove the work: it enters
direct reclaim 2.8x more often than the baseline (778 vs 277
allocstall_movable), and still does half the baseline's direct scanning
(44,737 vs 90,230 pgscan_direct). (c) cuts both instead -- reclaim
stalls 7x lower and direct scanning 20x lower (39 and 4,407).
That is why (b) recovers only half the gap -- the stall moves from
compaction into reclaim instead of going away.
If you agree this is the right direction, I am happy to send a v6 with
(c)'s behaviour plus the defrag_mode fix discussed in the v5 thread.
Thanks,
Salvatore
---
For reproducibility, here is the exact diff behind each measured row
above (all against v7.3-rc1).
(a) post-reclaim drain step skipped -- 70,615 tps:
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -4487,7 +4487,8 @@ __alloc_pages_direct_reclaim(gfp_t gfp_mask, unsigned int order,
* pages are pinned on the per-cpu lists or in high alloc reserves.
* Shrink them and try again
*/
- if (!page && !drained) {
+ if (!page && !drained &&
+ !(order > PAGE_ALLOC_COSTLY_ORDER && (gfp_mask & __GFP_NORETRY))) {
unreserve_highatomic_pageblock(ac, false);
drain_all_pages(NULL);
drained = true;
(b) compaction disabled only -- 107,210 tps:
diff --git a/include/linux/gfp.h b/include/linux/gfp.h
--- a/include/linux/gfp.h
+++ b/include/linux/gfp.h
@@ -380,7 +380,8 @@ static inline bool gfp_has_io_fs(gfp_t gfp)
*/
static inline bool gfp_compaction_allowed(gfp_t gfp_mask)
{
- return IS_ENABLED(CONFIG_COMPACTION) && (gfp_mask & __GFP_IO);
+ return IS_ENABLED(CONFIG_COMPACTION) && (gfp_mask & __GFP_IO) &&
+ (!(gfp_mask & __GFP_NORETRY) || (gfp_mask & __GFP_THISNODE));
}
AMAZON DEVELOPMENT CENTER ITALY SRL, viale Monte Grappa 3/5, 20124 Milano, Italia, Registro delle Imprese di Milano Monza Brianza Lodi REA n. 2504859, Capitale Sociale: 10.000 EUR i.v., Cod. Fisc. e P.IVA 10100050961, Societa con Socio Unico
next prev parent reply other threads:[~2026-09-23 9:26 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-04 11:56 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-23 9:25 ` Salvatore Dipietro [this message]
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 ` [PATCH 1/2] mm: page_alloc: do not give all non-blocking requests reserve access Johannes Weiner
2026-09-21 14:54 ` Matthew Wilcox
2026-09-21 15:58 ` Johannes Weiner
2026-09-22 11:52 ` Vlastimil Babka (SUSE)
2026-09-22 13:56 ` Johannes Weiner
2026-09-21 14:39 ` [PATCH 2/2] mm: page_alloc: remove ALLOC_NON_BLOCK from ALLOC_RESERVES Johannes Weiner
2026-09-22 12:06 ` Vlastimil Babka (SUSE)
2026-09-22 14:00 ` 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=20260923092512.101833-1-dipiets@amazon.it \
--to=dipiets@amazon.it \
--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=djwong@kernel.org \
--cc=hannes@cmpxchg.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=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®