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 v2 1/7] mm: factor out generic PTE batch detection from swap_pte_batch()
Date: Thu, 13 Aug 2026 11:57:30 +0200 [thread overview]
Message-ID: <f2dbbe27-ba09-4213-ab74-92db526dde7f@kernel.org> (raw)
In-Reply-To: <20260813-migrate-rmap-batch-v2-1-3c5424c555c7@amd.com>
On 8/13/26 06:23, Shivank Garg wrote:
> Factor out the generic PTE batch detection logic from swap_pte_batch()
> into softleaf_pte_batch() helper, so that it can be reused by upcoming
> patch that adds restore-side batching of migration entries.
>
> swap_pte_batch() now keeps only its swap-specific concerns and
> delegates the batch detection to softleaf_pte_batch().
>
> No functional changes intended.
>
> Signed-off-by: Shivank Garg <shivankg@amd.com>
> ---
> mm/internal.h | 36 +++++++++++++++++++++---------------
> 1 file changed, 21 insertions(+), 15 deletions(-)
>
> diff --git a/mm/internal.h b/mm/internal.h
> index a5d0488a54dc..1e1ab53b642e 100644
> --- a/mm/internal.h
> +++ b/mm/internal.h
> @@ -560,6 +560,26 @@ static inline void set_softleaf_ptes(struct mm_struct *mm, unsigned long addr,
> }
> }
>
> +static inline int softleaf_pte_batch(pte_t *start_ptep, int max_nr, pte_t pte)
> +{
> + pte_t expected_pte = pte_next_softleaf_offset(pte);
> + const pte_t *end_ptep = start_ptep + max_nr;
> + pte_t *ptep = start_ptep + 1;
> +
Wouldn't we want some way to make sure that the softleaf entries actually carry
offsets or pfns of sorts?
> + VM_WARN_ON(max_nr < 1);
> +
> + while (ptep < end_ptep) {
> + pte = ptep_get(ptep);
> +
> + if (!pte_same(pte, expected_pte))
> + break;
> + expected_pte = pte_next_softleaf_offset(expected_pte);
> + ptep++;
> + }
> +
> + return ptep - start_ptep;
> +}
> +
> /**
> * swap_pte_batch - detect a PTE batch for a set of contiguous swap entries
> * @start_ptep: Page table pointer for the first entry.
> @@ -577,23 +597,9 @@ static inline void set_softleaf_ptes(struct mm_struct *mm, unsigned long addr,
> */
> static inline int swap_pte_batch(pte_t *start_ptep, int max_nr, pte_t pte)
> {
> - pte_t expected_pte = pte_next_softleaf_offset(pte);
> - const pte_t *end_ptep = start_ptep + max_nr;
> - pte_t *ptep = start_ptep + 1;
> -
> - VM_WARN_ON(max_nr < 1);
> VM_WARN_ON(!softleaf_is_swap(softleaf_from_pte(pte)));
Any reason we cannot simply rename this thing and drop the VM_WARN_ON? I mean, a
caller can just do that.
--
Cheers,
David
next prev parent reply other threads:[~2026-08-13 9:57 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-13 4:23 [PATCH v2 0/7] mm: batch rmap walks during large folio migration Shivank Garg
2026-08-13 4:23 ` [PATCH v2 1/7] mm: factor out generic PTE batch detection from swap_pte_batch() Shivank Garg
2026-08-13 9:57 ` David Hildenbrand (Arm) [this message]
2026-08-14 8:00 ` Garg, Shivank
2026-08-16 7:48 ` Garg, Shivank
2026-08-13 4:23 ` [PATCH v2 2/7] mm/migrate: factor out migration PTE construction Shivank Garg
2026-08-13 4:23 ` [PATCH v2 3/7] mm/migrate: split remove_migration_pte_hugetlb() out of remove_migration_pte() Shivank Garg
2026-08-13 4:23 ` [PATCH v2 4/7] mm/migrate: batch the restore-side migration rmap walk Shivank Garg
2026-08-13 4:23 ` [PATCH v2 5/7] mm/rmap: factor out migration PTE construction Shivank Garg
2026-08-13 4:23 ` [PATCH v2 6/7] mm/rmap: split try_to_migrate_hugetlb_one() out of try_to_migrate_one() Shivank Garg
2026-08-13 4:23 ` [PATCH v2 7/7] mm/rmap: batch the unmap of large folios in try_to_migrate_one() Shivank Garg
2026-08-17 9:14 ` Lance Yang
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=f2dbbe27-ba09-4213-ab74-92db526dde7f@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.