Re: [RFC PATCH 0/9] introduce PGTY_mgt_entry page_type

[David Hildenbrand]

On 24.07.25 11:20, David Hildenbrand wrote:
> On 24.07.25 11:12, David Hildenbrand wrote:
> > On 24.07.25 11:09, Huan Yang wrote:
> > > 在 2025/7/24 16:59, David Hildenbrand 写道:
> > > > On 24.07.25 10:44, Huan Yang wrote:
> > > > > Summary
> > > > > ==
> > > > > This patchset reuses page_type to store migrate entry count during the
> > > > > period from migrate entry setup to removal, enabling accelerated VMA
> > > > > traversal when removing migrate entries, following a similar
> > > > > principle to
> > > > > early termination when folio is unmapped in try_to_migrate.
> > > >
> > > > I absolutely detest (ab)using page types for that, so no from my side
> > > > unless I am missing something important.
> > > >
> > > > > In my self-constructed test scenario, the migration time can be reduced
> > > >
> > > > How relevant is that in practice?
> > >
> > > IMO, any folio mapped < nr vma in mapping(anon_vma, addresss_space),
> > > will benefit from this.
> > >
> > > So, all pages that have been COW-ed by child processes can be skipped.
> >
> > For small anon folios, you could use the anon-exclusive marker to derive
> > "there can only be a single mapping".
> >
> > It's stored alongside the migration entry.
> >
> > So once you restored that single migration entry, you can just stop the
> > walk.
>
> Essentially, something (untested) like this:
>
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 425401b2d4e14..aa5bf96b1daee 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -421,6 +421,15 @@ static bool remove_migration_pte(struct folio *folio,
>    
>                   /* No need to invalidate - it was non-present before */
>                   update_mmu_cache(vma, pvmw.address, pvmw.pte);
> +
> +               /*
> +                * If the small anon folio is exclusive, here can be exactly one
> +                * page mapping -- the one we just restored.
> +                */
> +               if (!folio_test_large(folio) && (rmap_flags & RMAP_EXCLUSIVE)) {
> +                       page_vma_mapped_walk_done(&pvmw);
> +                       break;
> +               }
>           }
>    
>           return true;

Probably that won't really help I assume, because __folio_set_anon() 
will move the new anon folio under vma->anon_vma, not vma->anon_vma->root.

So I assume you mean that we had a COW-shared folio now mapped only into 
some VMAs (some mappings in other processes removed due to CoW or similar).

In that case aborting early can help.

Not in all cases though, just imagine that the very last VMA we're 
iterating maps the page. You have to iterate through all of them either 
way ... no way around that, really.

--
Cheers,

David / dhildenb