All of lore.kernel.org
 help / color / mirror / Atom feed
From: "David Hildenbrand (Arm)" <david@kernel.org>
To: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>,
	Imre Kaloz <kaloz@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 11:02:17 +0100	[thread overview]
Message-ID: <5dac5fd3-c2a6-4e1a-98fa-0fe1936b269d@kernel.org> (raw)
In-Reply-To: <8d4993cb2f2e5c3300514f1e2616e4a101488883.camel@physik.fu-berlin.de>

On 10/28/26 10:58, John Paul Adrian Glaubitz wrote:
> Hi David,
> 
> On Wed, 2026-10-28 at 10:22 +0100, David Hildenbrand (Arm) wrote:
>> On 10/28/26 10:16, Imre Kaloz wrote:
>>> Hi David,
>>>
>>>
>>> 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.
>>
>> Okay, so mremap() and reclaim memory performance concerns make you sleep bad at
>> night? :)
>>
>> Don't get me wrong, I know that running new kernels on old HW is fun.
>>
>> Last week a got upstream Linux running on a 32bit x86 notebook from 2007 with
>> the snap of a finger. Everything just works (using Alpine).
> 
> That's cool!
> 
>> I couldn't care less about performance. Nobody should.
> 
> Well, try to put it into some perspective: For some people, old hardware
> is all what they have and given the current high prices, I assume many
> people will be stuck with old hardware for a while now. Think of developing
> countries as well.

sparc64 machines?! cmon

> 
>> The biggest problem all of us with supporting old hardware is the maintanance
>> cost. Not just core-mm, but also things like ad-hoc page table walkers you are
>> adding we (from core-mm) might have to touch at some point.
> 
> Well, but if people are using it in the end, I think it's justified to support it.

No. Run stable kernels.

> 
>> If there is no good reason for the complexity, out it goes.
> 
> The patch doesn't really look that complex though. It adds an additional parameter
> to move_pte() which adds a few more lines of code. Not really overly complex, I think.

Follow the discussion.

> 
>> Because otherwise people will push more and more for removing legacy support
>> completely, and that's not what you want, right?
> 
> I don't think it's fair to make the kernel exclusive to very recent hardware only.

"Very recent" find the mistake.

(sorry, I'm unusually grumpy today)

-- 
Cheers,

David


  reply	other threads:[~2026-10-28 10:02 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
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) [this message]
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=5dac5fd3-c2a6-4e1a-98fa-0fe1936b269d@kernel.org \
    --to=david@kernel.org \
    --cc=akpm@linux-foundation.org \
    --cc=andreas@gaisler.com \
    --cc=davem@davemloft.net \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=jannh@google.com \
    --cc=kaloz@kernel.org \
    --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.