From: Byungchul Park <byungchul@sk.com>
To: "Garg, Shivank" <shivankg@amd.com>
Cc: akpm@linux-foundation.org, david@redhat.com, ziy@nvidia.com,
willy@infradead.org, matthew.brost@intel.com,
joshua.hahnjy@gmail.com, rakie.kim@sk.com, gourry@gourry.net,
ying.huang@linux.alibaba.com, apopple@nvidia.com,
lorenzo.stoakes@oracle.com, Liam.Howlett@oracle.com,
vbabka@suse.cz, rppt@kernel.org, surenb@google.com,
mhocko@suse.com, vkoul@kernel.org, lucas.demarchi@intel.com,
rdunlap@infradead.org, jgg@ziepe.ca, kuba@kernel.org,
justonli@chromium.org, ivecera@redhat.com, dave.jiang@intel.com,
Jonathan.Cameron@huawei.com, dan.j.williams@intel.com,
rientjes@google.com, Raghavendra.KodsaraThimmappa@amd.com,
bharata@amd.com, alirad.malek@zptcorp.com, yiannis@zptcorp.com,
weixugc@google.com, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, kernel_team@skhynix.com
Subject: Re: [RFC V3 6/9] mtcopy: introduce multi-threaded page copy routine
Date: Wed, 12 Nov 2025 11:12:17 +0900 [thread overview]
Message-ID: <20251112021217.GA45963@system.software.com> (raw)
In-Reply-To: <88ae0dfb-b10f-4829-8aa7-a681612704fa@amd.com>
On Thu, Nov 06, 2025 at 11:57:54AM +0530, Garg, Shivank wrote:
> On 10/20/2025 1:58 PM, Byungchul Park wrote:
> > Thanks for the great work.
> >
> > By the way, is it okay to use work queue? When the system is idle, this
> > patch will improve the migration performance, but when there are a lot
> > of other runnable tasks in the system, it might be worse than the
> > current one. That's gonna be even worse if there are some other tasks
> > that wait for the migration to end. It's worth noting that
> > padata_do_multithreaded() also uses work queue internally.
> >
> > I think, at worst, the performance should be same as is. Or am I
> > missing something?
> >
> > Byungchul
>
> Hi Byungchul,
>
> This was addressed by Zi in the mail:
> https://lore.kernel.org/linux-mm/61F6152C-A91E-453B-9521-34B7497AE532@nvidia.com
>
> So, there are some specific use cases that can benefit significantly when CPU cores are idle
Sure. I think so. I meant the mechanism using multi-threads would
better be performed for faster migration when a system is idle, but it'd
better avoid the aggressiveness when the system is busy.
Or we might observe a performance degradation due to this work.
Byungchul
> while GPUs or accelerators handle most of the workload.
> In such scenarios, migrating pages to and from device memory (GPU or AI accelerator) quickly
> is critical and ensure hot data is always available for accelerators.
>
> Thanks,
> Shivank
>
> >
> >> + per_cpu_item_idx = 0;
> >> + cpu++;
> >> + }
> >> + }
> >> + if (item_idx != nr_items)
> >> + pr_warn("%s: only %d out of %d pages are transferred\n",
> >> + __func__, item_idx - 1, nr_items);
> >> + }
> >> +
> >> + /* Wait until it finishes */
> >> + for (i = 0; i < total_mt_num; ++i) {
> >> + flush_work((struct work_struct *)work_items[i]);
> >> + /* retry if any copy fails */
> >> + if (work_items[i]->ret)
> >> + err = -EAGAIN;
> >> + }
> >> +
> >> +free_work_items:
> >> + for (cpu = 0; cpu < total_mt_num; ++cpu)
> >> + kfree(work_items[cpu]);
> >> +
> >> + return err;
> >> +}
> >> +
> >> +static struct kobject *mt_kobj_ref;
> >> +static struct kobj_attribute mt_offloading_attribute = __ATTR(offloading, 0664,
> >> + mt_offloading_show, mt_offloading_set);
> >> +static struct kobj_attribute mt_threads_attribute = __ATTR(threads, 0664,
> >> + mt_threads_show, mt_threads_set);
> >> +
> >> +static int __init cpu_mt_module_init(void)
> >> +{
> >> + int ret = 0;
> >> +
> >> + mt_kobj_ref = kobject_create_and_add("cpu_mt", kernel_kobj);
> >> + if (!mt_kobj_ref)
> >> + return -ENOMEM;
> >> +
> >> + ret = sysfs_create_file(mt_kobj_ref, &mt_offloading_attribute.attr);
> >> + if (ret)
> >> + goto out_offloading;
> >> +
> >> + ret = sysfs_create_file(mt_kobj_ref, &mt_threads_attribute.attr);
> >> + if (ret)
> >> + goto out_threads;
> >> +
> >> + is_dispatching = 0;
> >> +
> >> + return 0;
> >> +
> >> +out_threads:
> >> + sysfs_remove_file(mt_kobj_ref, &mt_offloading_attribute.attr);
> >> +out_offloading:
> >> + kobject_put(mt_kobj_ref);
> >> + return ret;
> >> +}
> >> +
> >> +static void __exit cpu_mt_module_exit(void)
> >> +{
> >> + /* Stop the MT offloading to unload the module */
> >> + mutex_lock(&migratecfg_mutex);
> >> + if (is_dispatching == 1) {
> >> + stop_offloading();
> >> + is_dispatching = 0;
> >> + }
> >> + mutex_unlock(&migratecfg_mutex);
> >> +
> >> + sysfs_remove_file(mt_kobj_ref, &mt_threads_attribute.attr);
> >> + sysfs_remove_file(mt_kobj_ref, &mt_offloading_attribute.attr);
> >> + kobject_put(mt_kobj_ref);
> >> +}
> >> +
> >> +module_init(cpu_mt_module_init);
> >> +module_exit(cpu_mt_module_exit);
> >> +
> >> +MODULE_LICENSE("GPL");
> >> +MODULE_AUTHOR("Zi Yan");
> >> +MODULE_DESCRIPTION("CPU_MT_COPY"); /* CPU Multithreaded Batch Migrator */
> >> --
> >> 2.43.0
next prev parent reply other threads:[~2025-11-12 2:12 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-09-23 17:47 [RFC V3 0/9] Accelerate page migration with batch copying and hardware offload Shivank Garg
2025-09-23 17:47 ` [RFC V3 1/9] mm/migrate: factor out code in move_to_new_folio() and migrate_folio_move() Shivank Garg
2025-10-02 10:30 ` Jonathan Cameron
2025-09-23 17:47 ` [RFC V3 2/9] mm/migrate: revive MIGRATE_NO_COPY in migrate_mode Shivank Garg
2025-09-23 17:47 ` [RFC V3 3/9] mm: Introduce folios_mc_copy() for batch copying folios Shivank Garg
2025-09-23 17:47 ` [RFC V3 4/9] mm/migrate: add migrate_folios_batch_move to batch the folio move operations Shivank Garg
2025-10-02 11:03 ` Jonathan Cameron
2025-10-16 9:17 ` Garg, Shivank
2025-09-23 17:47 ` [RFC V3 5/9] mm: add support for copy offload for folio Migration Shivank Garg
2025-10-02 11:10 ` Jonathan Cameron
2025-10-16 9:40 ` Garg, Shivank
2025-09-23 17:47 ` [RFC V3 6/9] mtcopy: introduce multi-threaded page copy routine Shivank Garg
2025-10-02 11:29 ` Jonathan Cameron
2025-10-20 8:28 ` Byungchul Park
2025-11-06 6:27 ` Garg, Shivank
2025-11-12 2:12 ` Byungchul Park [this message]
2025-09-23 17:47 ` [RFC V3 7/9] dcbm: add dma core batch migrator for batch page offloading Shivank Garg
2025-10-02 11:38 ` Jonathan Cameron
2025-10-16 9:59 ` Garg, Shivank
2025-09-23 17:47 ` [RFC V3 8/9] adjust NR_MAX_BATCHED_MIGRATION for testing Shivank Garg
2025-09-23 17:47 ` [RFC V3 9/9] mtcopy: spread threads across die " Shivank Garg
2025-09-24 1:49 ` [RFC V3 0/9] Accelerate page migration with batch copying and hardware offload Huang, Ying
2025-09-24 2:03 ` Zi Yan
2025-09-24 3:11 ` Huang, Ying
2025-09-24 3:22 ` Zi Yan
2025-10-02 17:10 ` 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=20251112021217.GA45963@system.software.com \
--to=byungchul@sk.com \
--cc=Jonathan.Cameron@huawei.com \
--cc=Liam.Howlett@oracle.com \
--cc=Raghavendra.KodsaraThimmappa@amd.com \
--cc=akpm@linux-foundation.org \
--cc=alirad.malek@zptcorp.com \
--cc=apopple@nvidia.com \
--cc=bharata@amd.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=david@redhat.com \
--cc=gourry@gourry.net \
--cc=ivecera@redhat.com \
--cc=jgg@ziepe.ca \
--cc=joshua.hahnjy@gmail.com \
--cc=justonli@chromium.org \
--cc=kernel_team@skhynix.com \
--cc=kuba@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=lucas.demarchi@intel.com \
--cc=matthew.brost@intel.com \
--cc=mhocko@suse.com \
--cc=rakie.kim@sk.com \
--cc=rdunlap@infradead.org \
--cc=rientjes@google.com \
--cc=rppt@kernel.org \
--cc=shivankg@amd.com \
--cc=surenb@google.com \
--cc=vbabka@suse.cz \
--cc=vkoul@kernel.org \
--cc=weixugc@google.com \
--cc=willy@infradead.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox