Linux-mm Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Zi Yan" <ziy@nvidia.com>
To: "Alistair Popple" <apopple@nvidia.com>,
	"Balbir Singh" <balbirs@nvidia.com>
Cc: "David Hildenbrand (Arm)" <david@kernel.org>,
	"Matthew Brost" <matthew.brost@intel.com>,
	"Andrew Morton" <akpm@linux-foundation.org>,
	"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>,
	"Kefeng Wang" <wangkefeng.wang@huawei.com>, <linux-mm@kvack.org>,
	<linux-kernel@vger.kernel.org>,
	"Sashiko" <sashiko-bot@kernel.org>
Subject: Re: [PATCH] mm/migrate_device: avoid overflowing migrate_vma collection arrays
Date: Tue, 14 Jul 2026 20:59:00 -0400	[thread overview]
Message-ID: <DJYQKBV5C3WQ.2A702GAYGPW71@nvidia.com> (raw)
In-Reply-To: <alXFS7BJWLwH6Wpt@nvdebian.thelocal>

On Tue Jul 14, 2026 at 1:30 AM EDT, Alistair Popple wrote:
> On 2026-07-14 at 10:10 +1000, Balbir Singh <balbirs@nvidia.com> wrote...
>> On 7/14/26 8:24 AM, Alistair Popple wrote:
>> > On 2026-07-14 at 01:39 +1000, Zi Yan <ziy@nvidia.com> wrote...
>> >> On 13 Jul 2026, at 11:25, David Hildenbrand (Arm) wrote:
>> >>
>> >>> On 7/13/26 17:20, Zi Yan wrote:
>> >>>> On 13 Jul 2026, at 8:57, David Hildenbrand (Arm) wrote:
>> >>>>
>> >>>>> On 7/10/26 17:35, Zi Yan wrote:
>> >>>>>>
>> >>>>>> Not all the time. After a folio split and PTE lock is dropped, there are
>> >>>>>> different cases:
>> >>>>>>
>> >>>>>> 1. no page table change, the collection grabs the PTE lock and continues;
>> >>>>>
>> >>>>> Yes.
>> >>>>>
>> >>>>>>
>> >>>>>> 2. some PTE(s) is changed, the same as 1 and the collection continues;
>> >>>>>
>> >>>>> Yes.
>> >>>>>
>> >>>>>>
>> >>>>>> 3. the PMD pointing to the PTE page table is changed to either a leaf
>> >>>>>>    PMD or an invalid PMD, the collection cannot grab the PTE lock to
>> >>>>>>    work on the remaming PTEs, since they are gone. For the collected
>> >>>>>>    PFNs (they are mapped more than once) and folios with elevated
>> >>>>>>    refcount (they are mapped once and unmapped here as an optimization),
>> >>>>>>    they will be processed later in migrate_vma_unmap(). Since
>> >>>>>>    migrate_vma_collect() is best effort, there is no need to revert and
>> >>>>>>    try to recollect from the beginning (to get that possible large
>> >>>>>>    folio or skip).
>> >>>>>
>> >>>>> Yes.
>> >>>>>
>> >>>>>>
>> >>>>>> BTW, recollection will be more feasible if migrate_vma_collect() does
>> >>>>>> not do unmap singly-mapped optimization, since in the case, no PTE is
>> >>>>>> changed, we just need to reset migrate->->cpages and migrate->npages and
>> >>>>>> restart from the beginning.
>> >>>>>>
>> >>>>>>
>> >>>>>> Right. The PTE page table should be gone and the original PMD, pointing
>> >>>>>> to the PTE page table, becomes a leaf PMD or an invalid PMD, since
>> >>>>>> someone changed it when the PTE lock is dropped.
>> >>>>>
>> >>>>> Right, so I guess we'd have to remember how far to rollback, and rollback would
>> >>>>> mean resetting migrate->->cpages and migrate->npages.
>> >>>>
>> >>>> For case 1 and 2, we do not roll back. For case 3, since the PMD is changed,
>> >>>> we just roll back to the start address and set migrate->cpages and migrate->npages
>> >>>> both to 0.
>> >>>
>> >>> Can't we walk multiple PMDs and have data already in there?
>> >>
>> >> migrate_vma_collect() is the pmd_entry of struct mm_walk_ops, so it only
>> >> walks a single PMD at a time.
>> >>
>> >>>
>> >>>>>
>> >>>>> And for the entries we rollback, we have to decide whether to folio_put() and
>> >>>>> whether to folio_unlock() [fault_folio != folio]. That's the confusing bit given
>> >>>>> that the code is rather "interesting".
>> >>>>
>> >>>> IMHO, it might be much cleaner to remove the “unmap the mapping if the folio is
>> >>>> only mapped once” optimization, so there is no need to roll back at all.
>> >>>
>> >>> I guess most folios are only mapped once. Do we have any numbers on that?
>> >>
>> >> I will defer the question to Balbir, Alistair, and Matthew.
>> > 
>> > Unfortunately previous tests that I've done showed the optimisation is critical
>> > to performance in the common case (ie. singly mapped folios).
>> > 
>> > I say unfortunately because I have similar feelings to others here about this
>> > code :) I tested this a while ago because I was trying to clean up the collect
>> > step by mostly removing it and replacing it with a hmm_range_fault() type thing,
>> > but the optimisation proved too important due to unmap having to do another
>> > rmap/page table walk.
>> > 
>> > I don't have the numbers on hand atm, but will recreate them just in case my
>> > recollection is faulty.
>> > 
>> 
>> I had a patch to add tracepoints to the code and some of that instrumentation
>> included this data. A combination of the trace points + hmm_tests will help us
>> get some data to start with.
>
> But hmm-test already has a nice bandwidth benchmark :) We just need to force
> the slow path. That used to be easier before I simplified the trylock handling
> but with the below patch applied I get quite a lot better perf from the
> optimisation. Note the patch isn't entirely correct as it assumes any locked
> page was locked by migrate_vma_collect_pmd but it's good enough for the purposes
> here.

Thanks for the numbers. If I read them correctly, the optimization
has about 3x throughput of unoptimzied version. The optimization has to
stay.

I will try to come up with a fix that resets collected PFNs, reverts
established migration entry along with putting folio ref, and restarts
from the beginning.

>
> Optimised results:
>
> HMM THP Migration Benchmark
> ---------------------------
> System page size: 4096 bytes
>
> === Small Buffer (0.5 MB) ===
>                      | With THP        | Without THP     | Improvement
> ---------------------------------------------------------------------
> Sys->Dev Migration   | 0.097 ms        | 0.120 ms        | 19.5%
> Dev->Sys Migration   | 0.061 ms        | 0.062 ms        | 0.4%
> S->D Throughput      | 5.05 GB/s      | 4.07 GB/s      | 24.2%
> D->S Throughput      | 7.96 GB/s      | 7.92 GB/s      | 0.4%
>
> === Half THP Size (1.0 MB) ===
>                      | With THP        | Without THP     | Improvement
> ---------------------------------------------------------------------
> Sys->Dev Migration   | 0.217 ms        | 0.212 ms        | -2.1%
> Dev->Sys Migration   | 0.136 ms        | 0.138 ms        | 1.2%
> S->D Throughput      | 4.51 GB/s      | 4.60 GB/s      | -2.1%
> D->S Throughput      | 7.17 GB/s      | 7.09 GB/s      | 1.2%
>
> === Single THP Size (2.0 MB) ===
>                      | With THP        | Without THP     | Improvement
> ---------------------------------------------------------------------
> Sys->Dev Migration   | 0.290 ms        | 0.506 ms        | 42.6%
> Dev->Sys Migration   | 0.095 ms        | 0.283 ms        | 66.3%
> S->D Throughput      | 6.72 GB/s      | 3.86 GB/s      | 74.3%
> D->S Throughput      | 20.52 GB/s      | 6.91 GB/s      | 197.0%
>
> === Two THP Size (4.0 MB) ===
>                      | With THP        | Without THP     | Improvement
> ---------------------------------------------------------------------
> Sys->Dev Migration   | 0.634 ms        | 1.026 ms        | 38.2%
> Dev->Sys Migration   | 0.195 ms        | 0.567 ms        | 65.6%
> S->D Throughput      | 6.16 GB/s      | 3.81 GB/s      | 61.8%
> D->S Throughput      | 20.05 GB/s      | 6.89 GB/s      | 191.1%
>
> === Four THP Size (8.0 MB) ===
>                      | With THP        | Without THP     | Improvement
> ---------------------------------------------------------------------
> Sys->Dev Migration   | 1.301 ms        | 2.593 ms        | 49.8%
> Dev->Sys Migration   | 0.541 ms        | 1.444 ms        | 62.5%
> S->D Throughput      | 6.01 GB/s      | 3.01 GB/s      | 99.3%
> D->S Throughput      | 14.45 GB/s      | 5.41 GB/s      | 167.0%
>
> === Eight THP Size (16.0 MB) ===
>                      | With THP        | Without THP     | Improvement
> ---------------------------------------------------------------------
> Sys->Dev Migration   | 3.853 ms        | 6.119 ms        | 37.0%
> Dev->Sys Migration   | 1.731 ms        | 3.354 ms        | 48.4%
> S->D Throughput      | 4.06 GB/s      | 2.55 GB/s      | 58.8%
> D->S Throughput      | 9.03 GB/s      | 4.66 GB/s      | 93.8%
>
> === One twenty eight THP Size (256.0 MB) ===
>                      | With THP        | Without THP     | Improvement
> ---------------------------------------------------------------------
> Sys->Dev Migration   | 70.022 ms        | 105.921 ms        | 33.9%
> Dev->Sys Migration   | 31.175 ms        | 55.393 ms        | 43.7%
> S->D Throughput      | 3.57 GB/s      | 2.36 GB/s      | 51.3%
> D->S Throughput      | 8.02 GB/s      | 4.51 GB/s      | 77.7%
>
>
> Non-optmisied results (ignore the THP column, I wasn't able to test the slow
> path so easily there so just skipped that bit of the test):
>
> === Small Buffer (0.5 MB) ===
>                      | With THP        | Without THP     | Improvement
> ---------------------------------------------------------------------
> Sys->Dev Migration   | 0.000 ms        | 0.321 ms        | 100.0%
> Dev->Sys Migration   | 0.000 ms        | 0.276 ms        | 100.0%
> S->D Throughput      | 0.00 GB/s      | 1.52 GB/s      | -100.0%
> D->S Throughput      | 0.00 GB/s      | 1.77 GB/s      | -100.0%
>
> === Half THP Size (1.0 MB) ===
>                      | With THP        | Without THP     | Improvement
> ---------------------------------------------------------------------
> Sys->Dev Migration   | 0.000 ms        | 0.660 ms        | 100.0%
> Dev->Sys Migration   | 0.000 ms        | 0.571 ms        | 100.0%
> S->D Throughput      | 0.00 GB/s      | 1.48 GB/s      | -100.0%
> D->S Throughput      | 0.00 GB/s      | 1.71 GB/s      | -100.0%
>
> === Single THP Size (2.0 MB) ===
>                      | With THP        | Without THP     | Improvement
> ---------------------------------------------------------------------
> Sys->Dev Migration   | 0.000 ms        | 1.385 ms        | 100.0%
> Dev->Sys Migration   | 0.000 ms        | 1.152 ms        | 100.0%
> S->D Throughput      | 0.00 GB/s      | 1.41 GB/s      | -100.0%
> D->S Throughput      | 0.00 GB/s      | 1.69 GB/s      | -100.0%
>
> === Two THP Size (4.0 MB) ===
>                      | With THP        | Without THP     | Improvement
> ---------------------------------------------------------------------
> Sys->Dev Migration   | 0.000 ms        | 2.863 ms        | 100.0%
> Dev->Sys Migration   | 0.000 ms        | 2.323 ms        | 100.0%
> S->D Throughput      | 0.00 GB/s      | 1.36 GB/s      | -100.0%
> D->S Throughput      | 0.00 GB/s      | 1.68 GB/s      | -100.0%
>
> === Four THP Size (8.0 MB) ===
>                      | With THP        | Without THP     | Improvement
> ---------------------------------------------------------------------
> Sys->Dev Migration   | 0.000 ms        | 6.199 ms        | 100.0%
> Dev->Sys Migration   | 0.000 ms        | 4.904 ms        | 100.0%
> S->D Throughput      | 0.00 GB/s      | 1.26 GB/s      | -100.0%
> D->S Throughput      | 0.00 GB/s      | 1.59 GB/s      | -100.0%
>
> === Eight THP Size (16.0 MB) ===
>                      | With THP        | Without THP     | Improvement
> ---------------------------------------------------------------------
> Sys->Dev Migration   | 0.000 ms        | 14.260 ms        | 100.0%
> Dev->Sys Migration   | 0.000 ms        | 10.457 ms        | 100.0%
> S->D Throughput      | 0.00 GB/s      | 1.10 GB/s      | -100.0%
> D->S Throughput      | 0.00 GB/s      | 1.49 GB/s      | -100.0%
>
> === One twenty eight THP Size (256.0 MB) ===
>                      | With THP        | Without THP     | Improvement
> ---------------------------------------------------------------------
> Sys->Dev Migration   | 0.000 ms        | 234.215 ms        | 100.0%
> Dev->Sys Migration   | 0.000 ms        | 167.061 ms        | 100.0%
> S->D Throughput      | 0.00 GB/s      | 1.07 GB/s      | -100.0%
> D->S Throughput      | 0.00 GB/s      | 1.50 GB/s      | -100.0%
>
> ---
>
> diff --git a/mm/migrate_device.c b/mm/migrate_device.c
> index 554754eb26ff..9f5563af8cd9 100644
> --- a/mm/migrate_device.c
> +++ b/mm/migrate_device.c
> @@ -397,7 +397,7 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
>                  * optimisation to avoid walking the rmap later with
>                  * try_to_migrate().
>                  */
> -               if (fault_folio == folio || folio_trylock(folio)) {
> +               if (fault_folio == folio) {
>                         bool anon_exclusive;
>                         pte_t swp_pte;
>  
> @@ -466,8 +466,16 @@ static int migrate_vma_collect_pmd(pmd_t *pmdp,
>                         if (pte_present(pte))
>                                 unmapped++;
>                 } else {
> -                       folio_put(folio);
> -                       mpfn = 0;
> +                       /*
> +                        * Slow path: couldn't lock the folio. Leave the PTE
> +                        * intact and collect it anyway; migrate_device_unmap()
> +                        * will lock it and use try_to_migrate() to install the
> +                        * migration entry via rmap walk.
> +                        *
> +                        * Keep the reference taken above for
> +                        * migrate_device_unmap() to drop.
> +                        */
> +                       migrate->cpages++;
>                 }
>  
>  next:
> @@ -605,6 +613,16 @@ static unsigned long migrate_device_unmap(unsigned long *src_pfns,
>                         folio_put(folio);
>                 }
>  
> +               /*
> +                * Fast-path pages (folio_trylock succeeded in collect) are
> +                * already locked. Slow-path pages were not locked during
> +                * collect; lock them now so try_to_migrate() and the finalize
> +                * path can rely on the folio being locked. This applies to
> +                * both regular and zone-device folios.
> +                */
> +               if (!folio_test_locked(folio))
> +                       folio_lock(folio);
> +
>                 if (folio_mapped(folio))
>                         try_to_migrate(folio, 0);
>  
> diff --git a/tools/testing/selftests/mm/hmm-tests.c b/tools/testing/selftests/mm/hmm-tests.c
> index e4c49699f3f7..3a673181b9ad 100644
> --- a/tools/testing/selftests/mm/hmm-tests.c
> +++ b/tools/testing/selftests/mm/hmm-tests.c
> @@ -2936,8 +2936,8 @@ TEST_F_TIMEOUT(hmm, benchmark_thp_migration, 120)
>                         break;
>  
>                 /* Test with THP */
> -               ASSERT_EQ(run_migration_benchmark(self->fd, 1, test_sizes[i],
> -                                       iterations, &thp_results), 0);
> +               // ASSERT_EQ(run_migration_benchmark(self->fd, 1, test_sizes[i],
> +               //                      iterations, &thp_results), 0);
>  
>                 /* Test without THP */
>                 ASSERT_EQ(run_migration_benchmark(self->fd, 0, test_sizes[i],




-- 
Best Regards,
Yan, Zi



  reply	other threads:[~2026-07-15  0:59 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-08  1:50 [PATCH] mm/migrate_device: avoid overflowing migrate_vma collection arrays Zi Yan
2026-07-08  2:45 ` Balbir Singh
2026-07-08  8:43 ` David Hildenbrand (Arm)
2026-07-08 14:35   ` Zi Yan
2026-07-08 14:43     ` Zi Yan
2026-07-10 11:30       ` Zi Yan
2026-07-10 11:56         ` David Hildenbrand (Arm)
2026-07-10 15:35           ` Zi Yan
2026-07-13 12:57             ` David Hildenbrand (Arm)
2026-07-13 15:20               ` Zi Yan
     [not found]                 ` <57cc487b-6ec3-4ca6-8735-f37644e2b0ab@kernel.org>
2026-07-13 15:39                   ` Zi Yan
2026-07-13 22:24                     ` Alistair Popple
2026-07-14  0:10                       ` Balbir Singh
2026-07-14  5:30                         ` Alistair Popple
2026-07-15  0:59                           ` Zi Yan [this message]
2026-07-10  2:54 ` Zi Yan

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=DJYQKBV5C3WQ.2A702GAYGPW71@nvidia.com \
    --to=ziy@nvidia.com \
    --cc=akpm@linux-foundation.org \
    --cc=apopple@nvidia.com \
    --cc=balbirs@nvidia.com \
    --cc=byungchul@sk.com \
    --cc=david@kernel.org \
    --cc=gourry@gourry.net \
    --cc=joshua.hahnjy@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=matthew.brost@intel.com \
    --cc=rakie.kim@sk.com \
    --cc=sashiko-bot@kernel.org \
    --cc=wangkefeng.wang@huawei.com \
    --cc=ying.huang@linux.alibaba.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