From: "Zi Yan" <ziy@nvidia.com>
To: "Joshua Hahn" <joshua.hahnjy@gmail.com>,
"Gregory Price" <gourry@gourry.net>
Cc: "Andrew Morton" <akpm@linux-foundation.org>,
"David Hildenbrand" <david@kernel.org>,
"Matthew Brost" <matthew.brost@intel.com>,
"Byungchul Park" <byungchul@sk.com>,
"Ying Huang" <ying.huang@linux.alibaba.com>,
"Alistair Popple" <apopple@nvidia.com>, <linux-mm@kvack.org>,
<linux-kernel@vger.kernel.org>, <kernel-team@meta.com>
Subject: Re: [PATCH] mm/migrate: wake kcompactd when huge folio migration fails in numa balancing
Date: Thu, 22 Oct 2026 14:59:17 -0400 [thread overview]
Message-ID: <DMBLJDUCMJI6.2RDRAALJ84225@nvidia.com> (raw)
In-Reply-To: <20261022172547.1181530-1-joshua.hahnjy@gmail.com>
On Thu Oct 22, 2026 at 1:25 PM EDT, Joshua Hahn wrote:
> NUMA balancing migrates a misplaced folio if migrate_balanced_pgdat()
> finds enough headroom on the destination node. For large folios, it then
> allocates a folio from the destination with GFP_TRANSHUGE_LIGHT, which
> wakes up neither kswapd nor kcompactd. This means a hot large folio
> trying to promote to a fragmented destination may never succeed in
> promotion even after repeated retries.
>
> Wake kcompactd on the target node when the destination allocation fails
> for a large folio. Don't wake kswapd, since this path can only be
> reached if there is enough free memory to service the allocation, but it
> is too fragmented to serve the large folio allocation.
>
> This patch has been A/B tested on tiered Meta systems (DRAM + CXL)
> running identical cacheing workloads. Without this patch, we accumulate
> around 4.5k failed THP migrations over the span of a day, while the host
> with this patch accumulates only about 80.
Is proactive compaction enabled? If yes, why does it not help?
>
> Those migration differences leads to about 25% reduced CXL bandwidth
> usage after applying this patch.
>
> Signed-off-by: Joshua Hahn <joshua.hahnjy@gmail.com>
> ---
> mm/migrate.c | 13 ++++++++++++-
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 7bdcdb57652f8..67364fe0851c0 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -2671,6 +2671,7 @@ static struct folio *alloc_misplaced_dst_folio(struct folio *src,
> int nid = (int) data;
> int order = folio_order(src);
> gfp_t gfp = __GFP_THISNODE;
> + struct folio *dst;
>
> if (order > 0)
> gfp |= GFP_TRANSHUGE_LIGHT;
> @@ -2679,7 +2680,17 @@ static struct folio *alloc_misplaced_dst_folio(struct folio *src,
> __GFP_NOWARN;
> gfp &= ~__GFP_RECLAIM;
> }
> - return __folio_alloc_node(gfp, order, nid);
> +
> + dst = __folio_alloc_node(gfp, order, nid);
> +
> + /*
> + * A node with enough free memory might still be too fragmented to serve
> + * a large folio. Wake kcompactd to help the next huge folio migration.
> + */
> + if (!dst && order > 0)
> + wakeup_kcompactd(NODE_DATA(nid), order, gfp_zone(gfp));
> +
> + return dst;
> }
>
> /*
--
Best Regards,
Yan, Zi
next prev parent reply other threads:[~2026-10-22 18:59 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-22 17:25 Joshua Hahn
2026-10-22 18:59 ` Zi Yan [this message]
2026-10-22 21:07 ` Joshua Hahn
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=DMBLJDUCMJI6.2RDRAALJ84225@nvidia.com \
--to=ziy@nvidia.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=byungchul@sk.com \
--cc=david@kernel.org \
--cc=gourry@gourry.net \
--cc=joshua.hahnjy@gmail.com \
--cc=kernel-team@meta.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=matthew.brost@intel.com \
--cc=ying.huang@linux.alibaba.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®