Re: [PATCH v3 4/4] mm: pass the number of PTEs to move_pte()

["David Hildenbrand (Arm)" <david@kernel.org>]

On 10/28/26 10:16, Imre Kaloz wrote:
> 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.

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).

I couldn't care less about performance. Nobody should.

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.

If there is no good reason for the complexity, out it goes.

Because otherwise people will push more and more for removing legacy support
completely, and that's not what you want, right?

> 
>> 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.

You know my answer :)

-- 
Cheers,

David