All of lore.kernel.org
 help / color / mirror / Atom feed
From: Imre Kaloz <kaloz@kernel.org>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: "David S. Miller" <davem@davemloft.net>,
	Andreas Larsson <andreas@gaisler.com>,
	"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, Magnus Lindholm <linmag7@gmail.com>
Subject: Re: [PATCH v3 4/4] mm: pass the number of PTEs to move_pte()
Date: Wed, 28 Oct 2026 10:16:29 +0100	[thread overview]
Message-ID: <20261028091631.8072-1-kaloz@kernel.org> (raw)
In-Reply-To: <dfe06aef-540a-4450-88ba-300a460007b7@kernel.org>

Hi David,

On 10/28/26 09:49, David Hildenbrand (Arm) wrote:
> But that's too complicated, requiring page table walks ....
> People running museum piece hardware and complaining about performance of mremap
> or memory reclaim should reconsider life choices.

I'm one of the museum folks myself, though more the kind who loves
running a modern kernel on old hardware than the kind who complains
about it :) A lot of these machines are still doing real work, and
these days not everyone can, or wants to, just buy a new computer.

Some of us spend our time keeping these platforms working, and I'm
not asking anyone else to carry that, which is why I tried to keep
all of it in sparc.

> So I'd say, make it as slow as you want while reducing core-MM complexity and
> not adding more arch complexity.

With C, move_pte() and __HAVE_ARCH_MOVE_PTE go away from
include/linux/pgtable.h and mm/mremap.c just like with A and B. The
walk lives in sparc's own flush_cache_range() and only runs on the
CPUs that need it.

B would be less sparc code, but every UltraSPARC I-IV machine would
pay 13-18% on reclaim for it, so I'd still lean towards C. If you feel
strongly about B, though, I'm happy to send that instead.


Best,
Imre


  reply	other threads:[~2026-10-28  9:17 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)
2026-10-27 21:26     ` Imre Kaloz
2026-10-28  8:49       ` David Hildenbrand (Arm)
2026-10-28  9:16         ` Imre Kaloz [this message]
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=20261028091631.8072-1-kaloz@kernel.org \
    --to=kaloz@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=andreas@gaisler.com \
    --cc=davem@davemloft.net \
    --cc=david@kernel.org \
    --cc=jannh@google.com \
    --cc=liam@infradead.org \
    --cc=linmag7@gmail.com \
    --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.