All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Shivank Garg <shivankg@amd.com>,
	Andrew Morton <akpm@linux-foundation.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>
Cc: 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 3/6] mm/migrate: split remove_migration_pte_hugetlb() out of remove_migration_pte()
Date: Tue, 14 Jul 2026 14:40:43 +0200	[thread overview]
Message-ID: <be2fedae-8caa-4a8f-9ede-cdf735e64357@kernel.org> (raw)
In-Reply-To: <20260712-migrate-rmap-batch-v1-3-872a734431d1@amd.com>

On 7/12/26 09:38, Shivank Garg wrote:
> remove_migration_pte() interleaves the regular folio path with the
> hugetlb path via folio_test_hugetlb() and CONFIG_HUGETLB_PAGE
> special cases. Simplify this by seprating the hugetlb handling into
> remove_migration_pte_hugetlb().
> 
> Factor out working-PTE construction from migration entry into
> migration_softleaf_entry_to_pte(), used by both paths.
> 
> While here, convert the VM_BUG_ON_FOLIO() to VM_WARN_ON_ONCE_FOLIO().
> 
> No functional change intended.
> 
> Signed-off-by: Shivank Garg <shivankg@amd.com>
> ---
>  mm/migrate.c | 153 ++++++++++++++++++++++++++++++++++++++---------------------
>  1 file changed, 98 insertions(+), 55 deletions(-)
> 
> diff --git a/mm/migrate.c b/mm/migrate.c
> index 222c8c15f782..8a098402b8c9 100644
> --- a/mm/migrate.c
> +++ b/mm/migrate.c
> @@ -345,6 +345,89 @@ struct rmap_walk_arg {
>  	bool map_unused_to_zeropage;
>  };
>  
> +static pte_t migration_softleaf_entry_to_pte(struct folio *folio, struct page *new,

"migration_entry" should be sufficient, right? It implies "softleaf".

> +		softleaf_t entry, pte_t old_pte, struct vm_area_struct *vma,
> +		rmap_t *rmap_flags)
> +{
> +	pte_t pte = mk_pte(new, READ_ONCE(vma->vm_page_prot));
> +
> +	if (!softleaf_is_migration_young(entry))
> +		pte = pte_mkold(pte);
> +	if (folio_test_dirty(folio) && softleaf_is_migration_dirty(entry))
> +		pte = pte_mkdirty(pte);
> +	if (pte_swp_soft_dirty(old_pte))
> +		pte = pte_mksoft_dirty(pte);
> +	else
> +		pte = pte_clear_soft_dirty(pte);
> +
> +	if (softleaf_is_migration_write(entry))
> +		pte = pte_mkwrite(pte, vma);
> +	else if (pte_swp_uffd(old_pte))
> +		pte = pte_mkuffd(pte);
> +
> +	/* See do_swap_page(): restore PAGE_NONE for RWP */
> +	if (pte_swp_uffd(old_pte) && userfaultfd_rwp(vma))
> +		pte = pte_modify(pte, PAGE_NONE);
> +
> +	if (folio_test_anon(folio) && !softleaf_is_migration_read(entry))
> +		*rmap_flags |= RMAP_EXCLUSIVE;
> +
> +	return pte;
> +}

Can you move splitting that out into a separate patch? IIUC you can do that even
without messing with the hugetlb stuff.

-- 
Cheers,

David


  reply	other threads:[~2026-07-14 12:40 UTC|newest]

Thread overview: 12+ 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) [this message]
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
2026-07-14 10:55 ` David Hildenbrand (Arm)

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=be2fedae-8caa-4a8f-9ede-cdf735e64357@kernel.org \
    --to=david@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=apopple@nvidia.com \
    --cc=bharata@amd.com \
    --cc=byungchul@sk.com \
    --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=shivankg@amd.com \
    --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.