From: "David Hildenbrand (Arm)" <david@kernel.org>
To: Imre Kaloz <kaloz@kernel.org>,
"David S. Miller" <davem@davemloft.net>,
Andreas Larsson <andreas@gaisler.com>
Cc: "Matthew Wilcox (Oracle)" <willy@infradead.org>,
"Mike Rapoport (IBM)" <rppt@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
"Liam R. Howlett" <liam@infradead.org>,
Lorenzo Stoakes <ljs@kernel.org>,
Vlastimil Babka <vbabka@kernel.org>, Jann Horn <jannh@google.com>,
Pedro Falcato <pfalcato@suse.de>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
sparclinux@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-mm@kvack.org
Subject: Re: [PATCH v3 4/4] mm: pass the number of PTEs to move_pte()
Date: Fri, 23 Oct 2026 22:53:09 +0200 [thread overview]
Message-ID: <409079fe-ab52-4389-9fe0-d7246eb27bad@kernel.org> (raw)
In-Reply-To: <2bc50d2a6829b49ee909e5bb943244859661a40b.1792609488.git.kaloz@kernel.org>
On 10/22/26 01:33, Imre Kaloz wrote:
> Since commit f822a9a81a31 ("mm: optimize mremap() by PTE batching"),
> move_ptes() moves a batch of PTEs mapping consecutive pages of a folio
> at a time, but calls move_pte() once per batch with the first PTE
> only. sparc64, the only architecture that overrides move_pte(), flushes
> from the D-cache the page that PTE maps when the move changes its
> colour, so the other pages of a batch would keep lines of the old
> colour. This cannot happen today only because sparc64 has no
> pte_batch_hint(), and mremap_folio_pte_batch() then never batches.
>
> Pass nr_ptes to move_pte(), as get_and_clear_ptes() takes it. The
> generic version ignores it, and sparc64 flushes every page of the
> batch.
>
> Signed-off-by: Imre Kaloz <kaloz@kernel.org>
> ---
> arch/sparc/include/asm/pgtable_64.h | 16 +++++++++-------
> include/linux/pgtable.h | 2 +-
> mm/mremap.c | 2 +-
> 3 files changed, 11 insertions(+), 9 deletions(-)
>
> diff --git a/arch/sparc/include/asm/pgtable_64.h b/arch/sparc/include/asm/pgtable_64.h
> index 1430489b9ac5..9ca787b3cbfe 100644
> --- a/arch/sparc/include/asm/pgtable_64.h
> +++ b/arch/sparc/include/asm/pgtable_64.h
> @@ -946,21 +946,23 @@ static inline void set_ptes(struct mm_struct *mm, unsigned long addr,
> set_pte_at((mm), (addr), (ptep), __pte(0UL))
>
> #ifdef DCACHE_ALIASING_POSSIBLE
> -/* This flushes only the page the PTE maps, so it relies on move_ptes()
> - * calling it for one PTE at a time, which the default pte_batch_hint()
> - * guarantees.
> +/* The nr PTEs map consecutive pages of one folio and all move by the
> + * same offset, so either every page of the batch aliases or none does.
> */
> #define __HAVE_ARCH_MOVE_PTE
> -#define move_pte(pte, old_addr, new_addr) \
> +#define move_pte(pte, old_addr, new_addr, nr) \
> ({ \
> pte_t newpte = (pte); \
> if (tlb_type != hypervisor && pte_present(pte)) { \
> unsigned long this_pfn = pte_pfn(pte); \
> + unsigned int i; \
> \
> if (pfn_valid(this_pfn) && \
> - (((old_addr) ^ (new_addr)) & (1 << 13))) \
> - flush_dcache_page_all(current->mm, \
> - pfn_to_page(this_pfn)); \
> + (((old_addr) ^ (new_addr)) & (1 << 13))) { \
> + for (i = 0; i < (nr); i++) \
> + flush_dcache_page_all(current->mm, \
> + pfn_to_page(this_pfn + i)); \
> + } \
> } \
> newpte; \
> })
> diff --git a/include/linux/pgtable.h b/include/linux/pgtable.h
> index 8c093c119e5a..b58c0e98994e 100644
> --- a/include/linux/pgtable.h
> +++ b/include/linux/pgtable.h
> @@ -1471,7 +1471,7 @@ static inline void arch_swap_restore(swp_entry_t entry, struct folio *folio)
> #endif
>
> #ifndef __HAVE_ARCH_MOVE_PTE
> -#define move_pte(pte, old_addr, new_addr) (pte)
> +#define move_pte(pte, old_addr, new_addr, nr) (pte)
> #endif
>
> #ifndef pte_accessible
> diff --git a/mm/mremap.c b/mm/mremap.c
> index e8df5cdb0ac9..7fcae7f0082d 100644
> --- a/mm/mremap.c
> +++ b/mm/mremap.c
> @@ -289,7 +289,7 @@ static int move_ptes(struct pagetable_move_control *pmc,
> force_flush = true;
> }
> pte = get_and_clear_ptes(mm, old_addr, old_ptep, nr_ptes);
> - pte = move_pte(pte, old_addr, new_addr);
> + pte = move_pte(pte, old_addr, new_addr, nr_ptes);
> pte = move_soft_dirty_pte(pte);
>
> if (need_clear_uffd_wp && pte_is_uffd_wp_marker(pte))
I hate move_pte() so much. And I hate sparc64 for requiring it. ;)
Is there some way we can avoid this
helper-that-shouldn't-exist-but-someone-hacked-it-in entirely?
If it makes sparc64 slightly slower #dontcare.
--
Cheers,
David
next prev parent reply other threads:[~2026-10-23 20:53 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-21 23:33 [PATCH v3 0/4] sparc64: D-cache alias flushing fixes Imre Kaloz
2026-10-21 23:33 ` [PATCH v3 1/4] sparc64: skip the trap block in xcall_deliver() when there is no target Imre Kaloz
2026-10-21 23:33 ` [PATCH v3 2/4] sparc64: flush only the aliased page, not its whole folio Imre Kaloz
2026-10-21 23:33 ` [PATCH v3 3/4] sparc64: flush vmalloc ranges from the D-cache on map and unmap Imre Kaloz
2026-10-21 23:33 ` [PATCH v3 4/4] mm: pass the number of PTEs to move_pte() Imre Kaloz
2026-10-23 17:17 ` Pedro Falcato
2026-10-23 20:53 ` David Hildenbrand (Arm) [this message]
2026-10-27 21:26 ` Imre Kaloz
2026-10-28 8:49 ` David Hildenbrand (Arm)
2026-10-28 9:16 ` Imre Kaloz
2026-10-28 9:22 ` David Hildenbrand (Arm)
2026-10-28 9:58 ` John Paul Adrian Glaubitz
2026-10-28 10:02 ` David Hildenbrand (Arm)
2026-10-28 10:12 ` Lorenzo Stoakes (ARM)
2026-10-28 10:17 ` Imre Kaloz
2026-10-28 13:57 ` Andreas Larsson
2026-10-28 13:59 ` David Hildenbrand (Arm)
2026-10-28 16:26 ` Imre Kaloz
2026-10-28 14:00 ` David Hildenbrand (Arm)
2026-10-22 8:20 ` [PATCH v3 0/4] sparc64: D-cache alias flushing fixes Stian Halseth
2026-10-23 9:22 ` Andreas Larsson
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=409079fe-ab52-4389-9fe0-d7246eb27bad@kernel.org \
--to=david@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=andreas@gaisler.com \
--cc=davem@davemloft.net \
--cc=jannh@google.com \
--cc=kaloz@kernel.org \
--cc=liam@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=mhocko@suse.com \
--cc=pfalcato@suse.de \
--cc=rppt@kernel.org \
--cc=sparclinux@vger.kernel.org \
--cc=surenb@google.com \
--cc=vbabka@kernel.org \
--cc=willy@infradead.org \
/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.