From: "Garg, Shivank" <shivankg@amd.com>
To: "rppt@kernel.org" <rppt@kernel.org>,
"byungchul@sk.com" <byungchul@sk.com>,
"rakie.kim@sk.com" <rakie.kim@sk.com>,
"vbabka@kernel.org" <vbabka@kernel.org>,
"harry@kernel.org" <harry@kernel.org>,
"ying.huang@linux.alibaba.com" <ying.huang@linux.alibaba.com>,
"riel@surriel.com" <riel@surriel.com>,
"david@kernel.org" <david@kernel.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
"matthew.brost@intel.com" <matthew.brost@intel.com>,
"surenb@google.com" <surenb@google.com>,
"gourry@gourry.net" <gourry@gourry.net>,
"ziy@nvidia.com" <ziy@nvidia.com>,
"jannh@google.com" <jannh@google.com>,
"liam@infradead.org" <liam@infradead.org>,
"mhocko@suse.com" <mhocko@suse.com>,
"ljs@kernel.org" <ljs@kernel.org>,
"lance.yang@linux.dev" <lance.yang@linux.dev>,
"joshua.hahnjy@gmail.com" <joshua.hahnjy@gmail.com>,
"apopple@nvidia.com" <apopple@nvidia.com>
Cc: "Rao, Bharata Bhasker" <bharata@amd.com>,
"kinseyho@google.com" <kinseyho@google.com>,
"dev.jain@arm.com" <dev.jain@arm.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"kmanaouil.dev@gmail.com" <kmanaouil.dev@gmail.com>,
"fvdl@google.com" <fvdl@google.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"weixugc@google.com" <weixugc@google.com>,
"rientjes@google.com" <rientjes@google.com>
Subject: Re: [PATCH v2 1/7] mm: factor out generic PTE batch detection from swap_pte_batch()
Date: Sun, 16 Aug 2026 07:48:48 +0000 [thread overview]
Message-ID: <89d8c2d6f35f7fdc3444ea3a62ccd244945d9644.camel@amd.com> (raw)
In-Reply-To: <2dddb3bb15dd9179388cef41a6564dbe722f9b1e.camel@amd.com>
On Fri, 2026-08-14 at 13:30 +0530, Shivank Garg wrote:
> On Thu, 2026-08-13 at 11:57 +0200, David Hildenbrand (Arm) wrote:
> > 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.
> >
>
> Thanks David,
>
> Agreed on both suggestions.
>
> I'll add VM_WARN_ON(!softleaf_is_swap(entry) && !softleaf_has_pfn(entry))
> in softleaf_pte_batch() for making sure it has offset/pfn and remove
> swap_pte_batch().
>
> Best regards,
> Shivank
diff --git a/mm/internal.h b/mm/internal.h
index a5d0488a54dc..31c7c6a04eac 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -561,29 +561,31 @@ static inline void set_softleaf_ptes(struct mm_struct *mm, unsigned long addr,
}
/**
- * swap_pte_batch - detect a PTE batch for a set of contiguous swap entries
+ * softleaf_pte_batch - detect a PTE batch for a set of contiguous softleaf entries
* @start_ptep: Page table pointer for the first entry.
* @max_nr: The maximum number of table entries to consider.
* @pte: Page table entry for the first entry.
*
- * Detect a batch of contiguous swap entries: consecutive (non-present) PTEs
- * containing swap entries all with consecutive offsets and targeting the same
- * swap type, all with matching swp pte bits.
+ * Detect consecutive (non-present) PTEs containing softleaf entries with
+ * consecutive offsets and matching PTE bits. @pte must contain a swap entry or
+ * a softleaf entry carrying PFN.
*
* max_nr must be at least one and must be limited by the caller so scanning
* cannot exceed a single page table.
*
* Return: the number of table entries in the batch.
*/
-static inline int swap_pte_batch(pte_t *start_ptep, int max_nr, pte_t pte)
+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 softleaf_t entry = softleaf_from_pte(pte);
+ pte_t expected_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)));
+ VM_WARN_ON(!softleaf_is_swap(entry) && !softleaf_has_pfn(entry));
+ expected_pte = pte_next_softleaf_offset(pte);
while (ptep < end_ptep) {
pte = ptep_get(ptep);
diff --git a/mm/madvise.c b/mm/madvise.c
index c179938097bf..8bed1c58c4bb 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -692,7 +692,7 @@ static int madvise_free_pte_range(pmd_t *pmd, unsigned long addr,
if (softleaf_is_swap(entry)) {
max_nr = (end - addr) / PAGE_SIZE;
- nr = swap_pte_batch(pte, max_nr, ptent);
+ nr = softleaf_pte_batch(pte, max_nr, ptent);
nr_swap -= nr;
swap_put_entries_direct(entry, nr);
clear_nonpresent_ptes(mm, addr, pte, nr);
diff --git a/mm/memory.c b/mm/memory.c
index a3d450d225ad..687796e1af84 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -1889,7 +1889,7 @@ static inline int zap_nonpresent_ptes(struct mmu_gather *tlb,
if (!should_zap_cows(details))
return 1;
- nr = swap_pte_batch(pte, max_nr, ptent);
+ nr = softleaf_pte_batch(pte, max_nr, ptent);
rss[MM_SWAPENTS] -= nr;
swap_put_entries_direct(entry, nr);
} else if (softleaf_is_migration(entry)) {
@@ -4758,7 +4758,7 @@ static bool can_swapin_thp(struct vm_fault *vmf, pte_t *ptep, int nr_pages)
* from different backends. And they are likely corner cases. Similar
* things might be added once zswap support large folios.
*/
- if (swap_pte_batch(ptep, nr_pages, pte) != nr_pages)
+ if (softleaf_pte_batch(ptep, nr_pages, pte) != nr_pages)
return false;
return true;
}
@@ -5062,7 +5062,7 @@ vm_fault_t do_swap_page(struct vm_fault *vmf)
folio_ptep = vmf->pte - idx;
folio_pte = ptep_get(folio_ptep);
if (!pte_same(folio_pte, pte_move_softleaf_offset(vmf->orig_pte, -idx)) ||
- swap_pte_batch(folio_ptep, nr, folio_pte) != nr)
+ softleaf_pte_batch(folio_ptep, nr, folio_pte) != nr)
goto check_folio;
page_idx = idx;
next prev parent reply other threads:[~2026-08-16 7:48 UTC|newest]
Thread overview: 20+ 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)
2026-08-14 8:00 ` Garg, Shivank
2026-08-16 7:48 ` Garg, Shivank [this message]
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-19 11:24 ` Karim Manaouil
2026-08-19 17:49 ` Garg, Shivank
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
2026-08-18 8:55 ` Miaohe Lin
2026-08-18 9:20 ` Lance Yang
2026-08-19 9:05 ` Miaohe Lin
2026-08-19 9:42 ` Huang, Ying
2026-08-19 9:57 ` Lance Yang
2026-08-19 10:09 ` 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=89d8c2d6f35f7fdc3444ea3a62ccd244945d9644.camel@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.