From: "Garg, Shivank" <shivankg@amd.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: David Hildenbrand <david@kernel.org>,
Lorenzo Stoakes <ljs@kernel.org>, Rik van Riel <riel@surriel.com>,
"Liam R. Howlett" <liam@infradead.org>,
Vlastimil Babka <vbabka@kernel.org>, Harry Yoo <harry@kernel.org>,
Jann Horn <jannh@google.com>, Lance Yang <lance.yang@linux.dev>,
Mike Rapoport <rppt@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>, 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>,
Karim Manaouil <kmanaouil.dev@gmail.com>,
"Frank van der Linden" <fvdl@google.com>,
Kinsey Ho <kinseyho@google.com>, Wei Xu <weixugc@google.com>,
Bharata B Rao <bharata@amd.com>,
David Rientjes <rientjes@google.com>, Dev Jain <dev.jain@arm.com>,
<linux-mm@kvack.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH 0/6] mm: batch rmap walks during large folio migration
Date: Tue, 14 Jul 2026 11:04:37 +0530 [thread overview]
Message-ID: <442897a7-7b17-4025-bfb0-fe2db8d64198@amd.com> (raw)
In-Reply-To: <20260713190516.0c669b5207667c893a9c0938@linux-foundation.org>
On 7/14/2026 7:35 AM, Andrew Morton wrote:
> On Sun, 12 Jul 2026 07:38:46 +0000 Shivank Garg <shivankg@amd.com> wrote:
>
>> Performance:
>>
>> AMD EPYC ZEN 3, 2-socket system (1 node per socket).
>> move_pages() migrating 1 GB from node 0 -> node 1, throughput
>> in GB/s:
>> batch- batch-restore +
>> folio vanilla restore unmap restore% restore+unmap%
>> 4K 2.98±0.09 2.95±0.07 3.06±0.05 -1.0% +2.6%
>> 64K 6.16±0.09 6.24±0.08 7.80±0.08 +1.3% +26.6%
>> 256K 6.85±0.06 6.85±0.09 9.54±0.19 +0.0% +39.3%
>> 1M 7.06±0.09 7.17±0.09 9.89±0.06 +1.5% +40.1%
>> 2M 10.97±0.17 10.67±0.13 10.69±0.15 -2.7% -2.6%
>>
>> In plain migration, the folio copy itself dominate the cost, so these rmap walk
>> savings are only partly visible end-to-end.
>> When the folio copy is batched-copy and offloaded to DMA engine [1], the copy is
>> no longer the bottlneck and rmap-walk batching translates into much larger gains:
>>
>> This series + [1], DMA Offload on PTDMA (DCBM), 16 channels:
>>
>> batch-copy
>> folio vanilla -offload(dcbm) dcbm+restore dcbm+restore+unmap
>> 4K 3.36 ± 0.10 4.16 ± 0.18 4.10 ± 0.14 4.12 ± 0.13
>> 64K 6.16 ± 0.47 9.63 ± 0.23 10.00 ± 0.33 14.63 ± 0.14
>> 256K 6.70 ± 0.09 12.98 ± 0.18 13.52 ± 0.15 32.30 ± 0.65 (2.38x)
>> 1M 6.99 ± 0.02 14.32 ± 0.67 14.84 ± 0.17 38.97 ± 1.03 (2.62x)
>> 2M 10.74 ± 0.29 64.25 ± 1.48 65.36 ± 1.00 64.97 ± 1.75
>
> Well dang.
>
> Thanks. I'll await reviewer input on this series.
>
> Sashiko said things:
> https://sashiko.dev/#/patchset/20260712-migrate-rmap-batch-v1-0-872a734431d1@amd.com
Thanks Andrew.
I'm working on this and the syzbot reported issue.
Best regards,
Shivank
next prev parent reply other threads:[~2026-07-14 5:34 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-07-12 7:38 [PATCH 0/6] mm: batch rmap walks during large folio migration Shivank Garg
2026-07-12 7:38 ` [PATCH 1/6] mm/rmap: Add batched version of folio_try_share_anon_rmap_pte Shivank Garg
2026-07-12 7:38 ` [PATCH 2/6] mm: factor out generic PTE batch detection from swap_pte_batch() Shivank Garg
2026-07-12 7:38 ` [PATCH 3/6] mm/migrate: split remove_migration_pte_hugetlb() out of remove_migration_pte() Shivank Garg
2026-07-14 12:40 ` David Hildenbrand (Arm)
2026-07-15 5:14 ` Garg, Shivank
2026-07-12 7:38 ` [PATCH 4/6] mm/migrate: batch the restore-side migration rmap walk Shivank Garg
2026-07-12 7:38 ` [PATCH 5/6] mm/rmap: split try_to_migrate_hugetlb_one() out of try_to_migrate_one() Shivank Garg
2026-07-12 7:38 ` [PATCH 6/6] mm/rmap: batch the unmap of large folios in try_to_migrate_one() Shivank Garg
2026-07-12 18:24 ` [syzbot ci] Re: mm: batch rmap walks during large folio migration syzbot ci
2026-07-14 2:05 ` [PATCH 0/6] " Andrew Morton
2026-07-14 5:34 ` Garg, Shivank [this message]
2026-07-14 10:55 ` David Hildenbrand (Arm)
2026-07-15 5:14 ` 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=442897a7-7b17-4025-bfb0-fe2db8d64198@amd.com \
--to=shivankg@amd.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=bharata@amd.com \
--cc=byungchul@sk.com \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=fvdl@google.com \
--cc=gourry@gourry.net \
--cc=harry@kernel.org \
--cc=jannh@google.com \
--cc=joshua.hahnjy@gmail.com \
--cc=kinseyho@google.com \
--cc=kmanaouil.dev@gmail.com \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--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=rakie.kim@sk.com \
--cc=riel@surriel.com \
--cc=rientjes@google.com \
--cc=rppt@kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=weixugc@google.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.