From: Shivank Garg <shivankg@amd.com>
To: Andrew Morton <akpm@linux-foundation.org>,
David Hildenbrand <david@kernel.org>, Zi Yan <ziy@nvidia.com>,
Matthew Brost <matthew.brost@intel.com>,
Joshua Hahn <joshua.hahnjy@gmail.com>,
Rakie Kim <rakie.kim@sk.com>, Byungchul Park <byungchul@sk.com>,
Gregory Price <gourry@gourry.net>,
Ying Huang <ying.huang@linux.alibaba.com>,
"Alistair Popple" <apopple@nvidia.com>,
Vlastimil Babka <vbabka@kernel.org>,
"Suren Baghdasaryan" <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
"Brendan Jackman" <brendan.jackman@linux.dev>,
Johannes Weiner <hannes@cmpxchg.org>, "SJ Park" <sj@kernel.org>,
Jason Gunthorpe <jgg@ziepe.ca>,
John Hubbard <jhubbard@nvidia.com>, Peter Xu <peterx@redhat.com>,
Miaohe Lin <linmiaohe@huawei.com>,
Naoya Horiguchi <nao.horiguchi@gmail.com>,
"Oscar Salvador" <osalvador@suse.de>,
Kairui Song <kasong@tencent.com>, Qi Zheng <qi.zheng@linux.dev>,
Shakeel Butt <shakeel.butt@linux.dev>,
Barry Song <baohua@kernel.org>,
Axel Rasmussen <axelrasmussen@google.com>,
Yuanchu Xie <yuanchu@google.com>, Wei Xu <weixugc@google.com>,
Lorenzo Stoakes <ljs@kernel.org>,
"Matthew Wilcox (Oracle)" <willy@infradead.org>,
Jan Kara <jack@suse.cz>, Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
"Alexander Viro" <viro@zeniv.linux.org.uk>,
Christian Brauner <brauner@kernel.org>,
Benjamin LaHaise <bcrl@kvack.org>, Chris Mason <clm@fb.com>,
David Sterba <dsterba@suse.com>,
Muchun Song <muchun.song@linux.dev>,
Dave Kleikamp <shaggy@kernel.org>,
Trond Myklebust <trondmy@kernel.org>,
Anna Schumaker <anna@kernel.org>, Mike Rapoport <rppt@kernel.org>,
Sean Christopherson <seanjc@google.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Bharata B Rao <bharata@amd.com>,
David Rientjes <rientjes@google.com>,
"Yiannis Nikolakopoulos" <yiannis@zptcorp.com>
Cc: <linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>,
<damon@lists.linux.dev>, <linux-cxl@vger.kernel.org>,
<linux-fsdevel@vger.kernel.org>, <linux-doc@vger.kernel.org>,
<linux-aio@kvack.org>, <linux-btrfs@vger.kernel.org>,
<jfs-discussion@lists.sourceforge.net>,
<linux-nfs@vger.kernel.org>, <kvm@vger.kernel.org>,
Shivank Garg <shivankg@amd.com>
Subject: [PATCH RFC 04/11] mm/migrate: use a dedicated list for hugetlb folios
Date: Wed, 2 Sep 2026 10:52:18 +0000 [thread overview]
Message-ID: <20260902-migrate-refactor-shivank-v1-4-9dcca87669c4@amd.com> (raw)
In-Reply-To: <20260902-migrate-refactor-shivank-v1-0-9dcca87669c4@amd.com>
migrate_hugetlbs() scans the full source list on every retry pass, even
though it only handles hugetlb folios.
Move hugetlb folios to a local list before migration and move any remaining
folios to @ret_folios. This avoids scanning unrelated folios and removes
the later hugetlb check from migrate_pages().
No functional change intended.
Signed-off-by: Shivank Garg <shivankg@amd.com>
---
mm/migrate.c | 43 ++++++++++++++++++++++---------------------
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/mm/migrate.c b/mm/migrate.c
index 510dfffa7235..7a136cec275f 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -1629,11 +1629,12 @@ struct migrate_pages_stats {
};
/*
- * Returns the number of hugetlb folios that were not migrated, or an error code
- * after NR_MAX_MIGRATE_PAGES_RETRY attempts or if no hugetlb folios are movable
- * any more because the list has become empty or no retryable hugetlb folios
- * exist any more. It is caller's responsibility to call putback_movable_pages()
- * only if ret != 0.
+ * Move hugetlb folios from @from to a local list and try to migrate each folio
+ * up to NR_MAX_MIGRATE_PAGES_RETRY times. Any remaining folios are moved to
+ * @ret_folios list.
+ *
+ * Return the number of failed folios, or a negative errno.
+ *
*/
static int migrate_hugetlbs(struct list_head *from, new_folio_t get_new_folio,
free_folio_t put_new_folio, unsigned long private,
@@ -1646,16 +1647,18 @@ static int migrate_hugetlbs(struct list_head *from, new_folio_t get_new_folio,
int nr_retry_pages = 0;
int pass = 0;
struct folio *folio, *folio2;
- int rc, nr_pages;
+ int rc, ret, nr_pages;
+ LIST_HEAD(hugetlbs);
+
+ list_for_each_entry_safe(folio, folio2, from, lru)
+ if (folio_test_hugetlb(folio))
+ list_move_tail(&folio->lru, &hugetlbs);
for (pass = 0; pass < NR_MAX_MIGRATE_PAGES_RETRY && retry; pass++) {
retry = 0;
nr_retry_pages = 0;
- list_for_each_entry_safe(folio, folio2, from, lru) {
- if (!folio_test_hugetlb(folio))
- continue;
-
+ list_for_each_entry_safe(folio, folio2, &hugetlbs, lru) {
nr_pages = folio_nr_pages(folio);
cond_resched();
@@ -1681,18 +1684,19 @@ static int migrate_hugetlbs(struct list_head *from, new_folio_t get_new_folio,
/*
* The rules are:
* 0: hugetlb folio will be put back
- * -EAGAIN: stay on the from list
- * -ENOMEM: stay on the from list
+ * -EAGAIN: stay on hugetlbs, retried by a later pass
+ * -ENOMEM: give up; rest of the list goes to ret_folios
* Other errno: put on ret_folios list
*/
- switch(rc) {
+ switch (rc) {
case -ENOMEM:
/*
* When memory is low, don't bother to try to migrate
* other folios, just exit.
*/
stats->nr_failed_pages += nr_pages + nr_retry_pages;
- return -ENOMEM;
+ ret = -ENOMEM;
+ goto out;
case -EAGAIN:
retry++;
nr_retry_pages += nr_pages;
@@ -1720,8 +1724,11 @@ static int migrate_hugetlbs(struct list_head *from, new_folio_t get_new_folio,
*/
nr_failed += retry;
stats->nr_failed_pages += nr_retry_pages;
+ ret = nr_failed;
+out:
+ list_splice_tail(&hugetlbs, ret_folios);
- return nr_failed;
+ return ret;
}
static void migrate_folios_move(struct list_head *src_folios,
@@ -2161,12 +2168,6 @@ int migrate_pages(struct list_head *from, new_folio_t get_new_folio,
again:
nr_pages = 0;
list_for_each_entry_safe(folio, folio2, from, lru) {
- /* Retried hugetlb folios will be kept in list */
- if (folio_test_hugetlb(folio)) {
- list_move_tail(&folio->lru, &ret_folios);
- continue;
- }
-
nr_pages += folio_nr_pages(folio);
if (nr_pages >= NR_MAX_BATCHED_MIGRATION)
break;
--
2.43.0
next prev parent reply other threads:[~2026-09-02 10:53 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 10:52 [PATCH RFC 00/11] mm/migrate: separate migration paths and carry migration policy Shivank Garg
2026-09-02 10:52 ` [PATCH RFC 01/11] mm/migrate: extract folio unmap phase Shivank Garg
2026-09-02 11:02 ` sashiko-bot
2026-09-02 10:52 ` [PATCH RFC 02/11] mm/migrate: handle retries in migrate_folios_move() Shivank Garg
2026-09-02 11:01 ` sashiko-bot
2026-09-02 10:52 ` [PATCH RFC 03/11] mm/migrate: factor out folio splitting on allocation failure Shivank Garg
2026-09-02 11:06 ` sashiko-bot
2026-09-02 10:52 ` Shivank Garg [this message]
2026-09-02 11:02 ` [PATCH RFC 04/11] mm/migrate: use a dedicated list for hugetlb folios sashiko-bot
2026-09-02 10:52 ` [PATCH RFC 05/11] mm/migrate: add a dedicated movable_ops migration pass Shivank Garg
2026-09-02 11:04 ` sashiko-bot
2026-09-02 10:52 ` [PATCH RFC 06/11] mm/migrate: rename migrate_pages_batch() to migrate_folios_batch() Shivank Garg
2026-09-02 11:02 ` sashiko-bot
2026-09-02 10:52 ` [PATCH RFC 07/11] mm/migrate: add migrate_lru_folios() entry point Shivank Garg
2026-09-02 11:03 ` sashiko-bot
2026-09-02 10:52 ` [PATCH RFC 08/11] mm/migrate: move LRU batching into migrate_lru_folios() Shivank Garg
2026-09-02 11:00 ` sashiko-bot
2026-09-02 10:52 ` [PATCH RFC 09/11] mm/migrate: thread migration policy through a control struct Shivank Garg
2026-09-02 11:06 ` sashiko-bot
2026-09-02 11:19 ` [sos-linux-ext-patches] " Garg, Shivank
2026-09-02 10:52 ` [PATCH RFC 10/11] mm/migrate: pass migrate_control to migrate_pages() Shivank Garg
2026-09-02 11:11 ` sashiko-bot
2026-09-02 10:52 ` [PATCH RFC 11/11] mm/migrate: pass migrate_control to migrate_folio() Shivank Garg
2026-09-02 11:10 ` Jan Kara
2026-09-02 11:10 ` sashiko-bot
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=20260902-migrate-refactor-shivank-v1-4-9dcca87669c4@amd.com \
--to=shivankg@amd.com \
--cc=akpm@linux-foundation.org \
--cc=anna@kernel.org \
--cc=apopple@nvidia.com \
--cc=axelrasmussen@google.com \
--cc=baohua@kernel.org \
--cc=bcrl@kvack.org \
--cc=bharata@amd.com \
--cc=brauner@kernel.org \
--cc=brendan.jackman@linux.dev \
--cc=byungchul@sk.com \
--cc=clm@fb.com \
--cc=corbet@lwn.net \
--cc=damon@lists.linux.dev \
--cc=david@kernel.org \
--cc=dsterba@suse.com \
--cc=gourry@gourry.net \
--cc=hannes@cmpxchg.org \
--cc=jack@suse.cz \
--cc=jfs-discussion@lists.sourceforge.net \
--cc=jgg@ziepe.ca \
--cc=jhubbard@nvidia.com \
--cc=joshua.hahnjy@gmail.com \
--cc=kasong@tencent.com \
--cc=kvm@vger.kernel.org \
--cc=linmiaohe@huawei.com \
--cc=linux-aio@kvack.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-nfs@vger.kernel.org \
--cc=ljs@kernel.org \
--cc=matthew.brost@intel.com \
--cc=mhocko@suse.com \
--cc=muchun.song@linux.dev \
--cc=nao.horiguchi@gmail.com \
--cc=osalvador@suse.de \
--cc=pbonzini@redhat.com \
--cc=peterx@redhat.com \
--cc=qi.zheng@linux.dev \
--cc=rakie.kim@sk.com \
--cc=rdunlap@infradead.org \
--cc=rientjes@google.com \
--cc=rppt@kernel.org \
--cc=seanjc@google.com \
--cc=shaggy@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=sj@kernel.org \
--cc=skhan@linuxfoundation.org \
--cc=surenb@google.com \
--cc=trondmy@kernel.org \
--cc=vbabka@kernel.org \
--cc=viro@zeniv.linux.org.uk \
--cc=weixugc@google.com \
--cc=willy@infradead.org \
--cc=yiannis@zptcorp.com \
--cc=ying.huang@linux.alibaba.com \
--cc=yuanchu@google.com \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.