From: "Garg, Shivank" <shivankg@amd.com>
To: "David Hildenbrand (Arm)" <david@kernel.org>, akpm@linux-foundation.org
Cc: kinseyho@google.com, weixugc@google.com, ljs@kernel.org,
Liam.Howlett@oracle.com, vbabka@kernel.org, willy@infradead.org,
rppt@kernel.org, surenb@google.com, mhocko@suse.com,
ziy@nvidia.com, matthew.brost@intel.com, joshua.hahnjy@gmail.com,
rakie.kim@sk.com, byungchul@sk.com, gourry@gourry.net,
ying.huang@linux.alibaba.com, apopple@nvidia.com,
dave@stgolabs.net, Jonathan.Cameron@huawei.com, rkodsara@amd.com,
vkoul@kernel.org, bharata@amd.com, sj@kernel.org,
rientjes@google.com, xuezhengchu@huawei.com, yiannis@zptcorp.com,
dave.hansen@intel.com, hannes@cmpxchg.org, jhubbard@nvidia.com,
peterx@redhat.com, riel@surriel.com, shakeel.butt@linux.dev,
stalexan@redhat.com, tj@kernel.org, nifan.cxl@gmail.com,
jic23@kernel.org, aneesh.kumar@kernel.org, nathan.lynch@amd.com,
Frank.li@nxp.com, djbw@kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, Mike Day <michael.day@amd.com>
Subject: Re: [PATCH 5/7] mm/migrate: add copy offload registration infrastructure
Date: Wed, 20 May 2026 20:54:45 +0530 [thread overview]
Message-ID: <18dd8ab0-2a3d-4b3b-9a93-5b44ceb559c5@amd.com> (raw)
In-Reply-To: <5a0ee441-3c0d-43b0-84f3-7e727ae042bd@kernel.org>
On 5/11/2026 9:16 PM, David Hildenbrand (Arm) wrote:
> On 4/28/26 17:50, Shivank Garg wrote:
>> Add a registration interface that lets a single offload provider
>> (DMA, multi-threaded CPU copy, etc) take over the batch folio copy
>> performed by migrate_pages_batch().
>>
>> The provider fills in a struct migrator with an offload_copy()
>> callback and calls migrate_offload_register(). Registration patches
>> the migrate_offload_copy() static_call and flips the
>> migrate_offload_enabled static branch. The migrate_offload_unregister()
>> reverts both.
>>
>> Whether a migration reason is batch-copy eligible is decided by the
>> core in migrate_offload_do_batch(). A migrator may decline a particular
>> batch (e.g. when nr_batch is too small to amortize setup) by returning
>> -EOPNOTSUPP, and the move phase falls back to per-folio CPU copy.
>>
>> Only one migrator can be active at a time. A second registration
>> returns -EBUSY, and only the active migrator can unregister itself.
>> The static_call dispatch is protected by SRCU so that the
>> synchronize_srcu() in unregister waits for all in-flight copy before
>> the module reference is dropped.
>>
>> Co-developed-by: Mike Day <michael.day@amd.com>
>> Signed-off-by: Mike Day <michael.day@amd.com>
>> Signed-off-by: Shivank Garg <shivankg@amd.com>
>
> MAINTAINERS file deserves some love (likely put the new files under the
> migration section)
Sure, will add this in the next posting.
[...]
>> +++ b/mm/migrate.c
>> @@ -44,6 +44,8 @@
>> #include <linux/memory-tiers.h>
>> #include <linux/pagewalk.h>
>> #include <linux/jump_label.h>
>> +#include <linux/static_call.h>
>> +#include <linux/migrate_copy_offload.h>
>>
>> #include <asm/tlbflush.h>
>>
>> @@ -54,6 +56,51 @@
>>
>> DEFINE_STATIC_KEY_FALSE(migrate_offload_enabled);
>>
>> +#ifdef CONFIG_MIGRATION_COPY_OFFLOAD
>> +DEFINE_SRCU(migrate_offload_srcu);
>> +DEFINE_STATIC_CALL(migrate_offload_copy, folios_mc_copy);
>> +
>> +static bool migrate_offload_do_batch(int reason)
>> +{
>> + if (!static_branch_unlikely(&migrate_offload_enabled))
>> + return false;
>> +
>> + switch (reason) {
>> + case MR_COMPACTION:
>> + case MR_SYSCALL:
>> + case MR_DEMOTION:
>> + case MR_NUMA_MISPLACED:
>> + return true;
>> + default:
>> + return false;
>> + }
>> +}
>> +
>> +static int migrate_offload_batch_copy(struct list_head *dst_batch,
>> + struct list_head *src_batch,
>> + unsigned int nr_batch)
>> +{
>> + int idx, rc;
>> +
>> + idx = srcu_read_lock(&migrate_offload_srcu);
>> + rc = static_call(migrate_offload_copy)(dst_batch, src_batch, nr_batch);
>> + srcu_read_unlock(&migrate_offload_srcu, idx);
>> + return rc;
>> +}
>> +#else
>> +static bool migrate_offload_do_batch(int reason)
>> +{
>> + return false;
>> +}
>> +
>> +static int migrate_offload_batch_copy(struct list_head *dst_batch,
>> + struct list_head *src_batch,
>> + unsigned int nr_batch)
>> +{
>> + return -EOPNOTSUPP;
>> +}
>> +#endif
>
> Can't all that go to migrate_copy_offload.(hc) Looks like a clean interface form
> migrate.c, no?
>
Yes, Will do.
>> +
>> static const struct movable_operations *offline_movable_ops;
>> static const struct movable_operations *zsmalloc_movable_ops;
>>
>> @@ -1833,7 +1880,7 @@ static int migrate_pages_batch(struct list_head *from,
>> struct folio *folio, *folio2, *dst = NULL;
>> int rc, rc_saved = 0, nr_pages;
>> unsigned int nr_batch = 0;
>> - bool batch_copied = false;
>> + bool do_batch = false, batch_copied = false;
>> LIST_HEAD(unmap_batch);
>> LIST_HEAD(dst_batch);
>> LIST_HEAD(unmap_single);
>> @@ -1843,6 +1890,8 @@ static int migrate_pages_batch(struct list_head *from,
>> VM_WARN_ON_ONCE(mode != MIGRATE_ASYNC &&
>> !list_empty(from) && !list_is_singular(from));
>>
>> + do_batch = migrate_offload_do_batch(reason);
>> +
>> for (pass = 0; pass < nr_pass && retry; pass++) {
>> retry = 0;
>> thp_retry = 0;
>> @@ -1984,8 +2033,7 @@ static int migrate_pages_batch(struct list_head *from,
>> nr_retry_pages += nr_pages;
>> break;
>> case 0:
>> - if (static_branch_unlikely(&migrate_offload_enabled) &&
>> - folio_supports_batch_copy(folio)) {
>> + if (do_batch && folio_supports_batch_copy(folio)) {
>
> I was about to say, the migrate_offload_enabled usage in the previous patch
> looks off.
>
> Can you move that to this patch here, and use in the previous patch simply a
> default migrate_offload_do_batch() that simply returns "false" ?
>
Yes, will do.
This is more clean.
Thanks,
Shivank
next prev parent reply other threads:[~2026-05-20 15:25 UTC|newest]
Thread overview: 67+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-28 15:50 [PATCH 0/7] Accelerate page migration with batch copying and hardware offload Shivank Garg
2026-04-28 15:50 ` [PATCH 1/7] mm/migrate: rename PAGE_ migration flags to FOLIO_ Shivank Garg
2026-04-30 9:07 ` Huang, Ying
2026-05-18 16:54 ` Jonathan Cameron
2026-05-18 23:51 ` Zi Yan
2026-06-09 5:34 ` Dev Jain
2026-06-09 6:17 ` Garg, Shivank
2026-06-09 6:23 ` Dev Jain
2026-04-28 15:50 ` [PATCH 2/7] mm/migrate: use migrate_info field instead of private Shivank Garg
2026-05-07 9:43 ` Huang, Ying
2026-05-11 15:22 ` David Hildenbrand (Arm)
2026-05-18 16:56 ` Jonathan Cameron
2026-04-28 15:50 ` [PATCH 3/7] mm/migrate: skip data copy for already-copied folios Shivank Garg
2026-05-11 15:35 ` David Hildenbrand (Arm)
2026-05-20 15:21 ` Garg, Shivank
2026-06-08 11:26 ` Garg, Shivank
2026-06-08 15:18 ` David Hildenbrand (Arm)
2026-06-08 15:41 ` Zi Yan
2026-06-08 15:43 ` David Hildenbrand (Arm)
2026-06-08 19:32 ` Garg, Shivank
2026-06-09 12:55 ` David Hildenbrand (Arm)
2026-06-08 15:09 ` David Hildenbrand (Arm)
2026-04-28 15:50 ` [PATCH 4/7] mm/migrate: add batch-copy path in migrate_pages_batch Shivank Garg
2026-05-11 15:40 ` David Hildenbrand (Arm)
2026-05-20 15:06 ` Garg, Shivank
2026-06-08 15:25 ` David Hildenbrand (Arm)
2026-06-08 15:36 ` Zi Yan
2026-06-08 20:40 ` Garg, Shivank
2026-06-08 21:17 ` Karim Manaouil
2026-05-21 13:20 ` Garg, Shivank
2026-04-28 15:50 ` [PATCH 5/7] mm/migrate: add copy offload registration infrastructure Shivank Garg
2026-05-11 15:46 ` David Hildenbrand (Arm)
2026-05-20 15:24 ` Garg, Shivank [this message]
2026-05-11 15:50 ` David Hildenbrand (Arm)
2026-05-20 15:22 ` Garg, Shivank
2026-05-25 2:16 ` David Rientjes
2026-05-25 2:19 ` David Rientjes
2026-06-11 9:55 ` Karim Manaouil
2026-06-11 18:44 ` Zi Yan
2026-04-28 15:50 ` [PATCH 6/7] drivers/migrate_offload: add DMA batch copy driver (dcbm) Shivank Garg
2026-06-09 0:00 ` Karim Manaouil
2026-06-09 7:31 ` Garg, Shivank
2026-06-09 16:17 ` Karim Manaouil
2026-06-10 12:26 ` Shivank Garg
2026-06-19 16:07 ` [PATCH 6/7] drivers/migrate_offload: add DMA batch copy driver (dcbm) Karim Manaouil
2026-06-19 16:32 ` Karim Manaouil
2026-06-22 10:03 ` Garg, Shivank
2026-04-28 15:50 ` [PATCH 7/7] mm/migrate: adjust NR_MAX_BATCHED_MIGRATION for testing Shivank Garg
2026-04-28 17:11 ` [PATCH 0/7] Accelerate page migration with batch copying and hardware offload Garg, Shivank
2026-04-28 19:33 ` David Hildenbrand (Arm)
2026-04-29 5:51 ` Garg, Shivank
2026-04-30 8:47 ` Huang, Ying
2026-05-08 11:04 ` Garg, Shivank
2026-05-08 11:28 ` Huang, Ying
2026-05-08 12:34 ` Garg, Shivank
2026-05-09 7:49 ` Huang, Ying
2026-05-10 15:03 ` Garg, Shivank
2026-05-12 2:15 ` Huang, Ying
2026-05-20 15:23 ` Garg, Shivank
2026-05-07 9:58 ` Huang, Ying
2026-05-11 15:19 ` David Hildenbrand (Arm)
2026-05-12 1:45 ` Huang, Ying
2026-05-11 15:53 ` David Hildenbrand (Arm)
2026-05-12 2:35 ` Huang, Ying
2026-05-12 6:34 ` David Hildenbrand (Arm)
2026-05-14 6:42 ` Huang, Ying
2026-05-20 15:35 ` Garg, Shivank
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=18dd8ab0-2a3d-4b3b-9a93-5b44ceb559c5@amd.com \
--to=shivankg@amd.com \
--cc=Frank.li@nxp.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=aneesh.kumar@kernel.org \
--cc=apopple@nvidia.com \
--cc=bharata@amd.com \
--cc=byungchul@sk.com \
--cc=dave.hansen@intel.com \
--cc=dave@stgolabs.net \
--cc=david@kernel.org \
--cc=djbw@kernel.org \
--cc=gourry@gourry.net \
--cc=hannes@cmpxchg.org \
--cc=jhubbard@nvidia.com \
--cc=jic23@kernel.org \
--cc=joshua.hahnjy@gmail.com \
--cc=kinseyho@google.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=matthew.brost@intel.com \
--cc=mhocko@suse.com \
--cc=michael.day@amd.com \
--cc=nathan.lynch@amd.com \
--cc=nifan.cxl@gmail.com \
--cc=peterx@redhat.com \
--cc=rakie.kim@sk.com \
--cc=riel@surriel.com \
--cc=rientjes@google.com \
--cc=rkodsara@amd.com \
--cc=rppt@kernel.org \
--cc=shakeel.butt@linux.dev \
--cc=sj@kernel.org \
--cc=stalexan@redhat.com \
--cc=surenb@google.com \
--cc=tj@kernel.org \
--cc=vbabka@kernel.org \
--cc=vkoul@kernel.org \
--cc=weixugc@google.com \
--cc=willy@infradead.org \
--cc=xuezhengchu@huawei.com \
--cc=yiannis@zptcorp.com \
--cc=ying.huang@linux.alibaba.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.