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 00/11] mm/migrate: separate migration paths and carry migration policy
Date: Wed, 2 Sep 2026 10:52:14 +0000 [thread overview]
Message-ID: <20260902-migrate-refactor-shivank-v1-0-9dcca87669c4@amd.com> (raw)
migrate_pages() handles hugetlb folios, movable_ops pages and LRU folios,
although their locking, mapping and retry requirements differ. It already
dispatches hugetlb folios to a dedicated engine but movable_ops
pages still pass through the regular folio unmap and move machinery.
Migration policy has a separate interface problem. migrate_mode describes
blocking discipline, but it is passed independently from migrate_reason
through the core, and only migrate_mode reaches
address_space_operations->migrate_folio(). Adding another policy dimension
therefore requires more positional arguments, an overloaded mode or side
state. [3]
This series separates the migration paths (classes) for movable_ops pages
and LRU folios, moves LRU policy into the LRU engine, and carries mode and
reason through struct migrate_control.
Thanks to Zi Yan and David Hildenbrand for the discussions and suggestions
that helped shape this series. I also used AI tools (Opus 5, GPT-5.6 Sol)
to refine my ideas, identify the edge-cases/bugs.
Old flow
========
migrate_pages(mode, reason)
|
+-- migrate_hugetlbs()
| `-- scan the mixed source list (from) on each retry
|
`-- split the remaining list into batches
|
+-- MIGRATE_ASYNC
| `-- migrate_pages_batch()
| inline unmap/retry -> flush -> move/retry
|
`-- MIGRATE_SYNC[_LIGHT]
`-- migrate_pages_sync()
+-- try async batch pre-pass
`-- retry failures one at a time through
migrate_pages_batch()
movable_ops pages are identified by branches inside the batch unmap and
move paths.
New flow
========
migrate_pages(ctl)
|
+-- migrate_hugetlbs()
| `-- collect and retry hugetlb folios
|
+-- migrate_movable_ops_pages()
| `-- allocate, lock, invoke the movable_ops callback and retry
|
`-- migrate_lru_folios()
`-- form bounded LRU batches
`-- __migrate_lru_folios()
+-- async: migrate_folios_batch()
`-- sync:
+-- async batch pre-pass
`-- retry failures one at a time
migrate_folios_batch()
|
+-- migrate_folios_unmap()
+-- try_to_unmap_flush()
+-- migrate_folios_move()
`-- migrate_folios_undo()
migrate_pages() now only dispatches classes. Each entry owns its lists and
retries; the LRU entry also owns batching and synchronous fallback.
Motivation
==========
This refactor makes the migration control flow easier to follow and gives
new optimizations clear boundaries and insertion points.
Separating movable_ops also prepares for memdescs, where these pages are
expected to lose their folio representation and folio->lru handoff. The
current list interface remains, but its folio dependencies are now isolated.
struct migrate_control is caller-owned, stack allocated and passed as const.
It carries mode and reason through migrate_pages() and ->migrate_folio(),
and provide place for future extension to policy. This is one-time pain of
updating callers, but doing it once avoids repeating that churn whenever
a new use case or optimization need additional policy.
Follow-on
=========
This series establishes the class, phase and policy boundaries without
adding copy implementation. Possible follow-on use looks like:
Yiannis and Alirad's RFC adds an asynchronous non-temporal mode and updates
existing asynchronous-mode checks. [1] A separate policy field would keep
cache behavior independent of blocking discipline.
/* migrate_pages() caller: demote_folio_list() */
ctl.reason = MR_DEMOTION; /* migration reason - already exists */
ctl.mode = MIGRATE_ASYNC; /* blocking discipline - already exists */
ctl.cache_hint = MIGRATE_COPY_NT; /* caching intent- new policy */
__migrate_folio(..., ctl); /* NT/offload based on caller's hint*/
`-> folio_mc_copy() or folio_mc_copy_nt() or ...
My batch-copy/offload series [2] can extend migrate_control to take caller's
preference of copy engines (like DMA offload, multi-threaded copy, etc.) or
batch size. Some of this may remain wishful thinking but that is what the
RFC is for :)
Behavior Changes
================
No functional change is intended for the LRU and hugetlb migration paths.
The movable_ops pass has three intentional differences:
- movable_ops pages are attempted before LRU folios;
- movable_ops pages no longer use the LRU asynchronous pre-pass.
synchronous callers use their requested mode from the first attempt.
- movable_ops callback returning -EAGAIN releases the destination, so
retry allocates a new one.
Unmigrated pages are still returned through the original source list.
[1] https://lore.kernel.org/r/20260730-rfc-nt-demote-v2-0-452dbe3b5073@zptcorp.com
[2] https://lore.kernel.org/r/20260630-shivank-batch-migrate-offload-v6-0-da95d7e8b8a2@amd.com
[3] https://lore.kernel.org/r/cae6ab98-3441-38bd-1e07-4586a85cdc74@google.com
---
Shivank Garg (11):
mm/migrate: extract folio unmap phase
mm/migrate: handle retries in migrate_folios_move()
mm/migrate: factor out folio splitting on allocation failure
mm/migrate: use a dedicated list for hugetlb folios
mm/migrate: add a dedicated movable_ops migration pass
mm/migrate: rename migrate_pages_batch() to migrate_folios_batch()
mm/migrate: add migrate_lru_folios() entry point
mm/migrate: move LRU batching into migrate_lru_folios()
mm/migrate: thread migration policy through a control struct
mm/migrate: pass migrate_control to migrate_pages()
mm/migrate: pass migrate_control to migrate_folio()
Documentation/filesystems/locking.rst | 2 +-
Documentation/filesystems/vfs.rst | 7 +-
fs/aio.c | 2 +-
fs/btrfs/disk-io.c | 5 +-
fs/btrfs/inode.c | 6 +-
fs/hugetlbfs/inode.c | 4 +-
fs/jfs/jfs_metapage.c | 14 +-
fs/nfs/internal.h | 2 +-
fs/nfs/write.c | 8 +-
include/linux/buffer_head.h | 6 +-
include/linux/fs.h | 6 +-
include/linux/migrate.h | 7 +-
include/linux/migrate_mode.h | 14 +
include/linux/pagemap.h | 2 +-
mm/compaction.c | 8 +-
mm/damon/ops-common.c | 7 +-
mm/gup.c | 7 +-
mm/memory-failure.c | 6 +-
mm/memory_hotplug.c | 6 +-
mm/mempolicy.c | 13 +-
mm/migrate.c | 717 ++++++++++++++++++++++------------
mm/page_alloc.c | 6 +-
mm/secretmem.c | 3 +-
mm/vmscan.c | 7 +-
virt/kvm/guest_memfd.c | 2 +-
25 files changed, 563 insertions(+), 304 deletions(-)
---
base-commit: cee9395acd8043be0644b25c34bfa86623f2b935
change-id: 20260824-migrate-refactor-shivank-4ee3949fcdcb
Best regards,
--
Shivank Garg <shivankg@amd.com>
next reply other threads:[~2026-09-02 10:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-02 10:52 Shivank Garg [this message]
2026-09-02 10:52 ` [PATCH RFC 01/11] mm/migrate: extract folio unmap phase Shivank Garg
2026-09-02 10:52 ` [PATCH RFC 02/11] mm/migrate: handle retries in migrate_folios_move() Shivank Garg
2026-09-02 10:52 ` [PATCH RFC 03/11] mm/migrate: factor out folio splitting on allocation failure Shivank Garg
2026-09-02 10:52 ` [PATCH RFC 04/11] mm/migrate: use a dedicated list for hugetlb folios Shivank Garg
2026-09-02 10:52 ` [PATCH RFC 05/11] mm/migrate: add a dedicated movable_ops migration pass Shivank Garg
2026-09-02 10:52 ` [PATCH RFC 06/11] mm/migrate: rename migrate_pages_batch() to migrate_folios_batch() Shivank Garg
2026-09-02 10:52 ` [PATCH RFC 07/11] mm/migrate: add migrate_lru_folios() entry point Shivank Garg
2026-09-02 10:52 ` [PATCH RFC 08/11] mm/migrate: move LRU batching into migrate_lru_folios() Shivank Garg
2026-09-02 10:52 ` [PATCH RFC 09/11] mm/migrate: thread migration policy through a control struct Shivank Garg
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 10:52 ` [PATCH RFC 11/11] mm/migrate: pass migrate_control to migrate_folio() Shivank Garg
2026-09-02 11:10 ` Jan Kara
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-0-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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox