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

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

On 10/27/26 22:26, Imre Kaloz wrote:
> Hi David,
> 
> On 10/23/26 22:53, David Hildenbrand (Arm) wrote:
>> 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.
> 
> I tried three ways of doing that on an Ultra 45 (UltraSPARC IIIi, two
> CPUs), all with move_pte() removed entirely:
> 
>  A) sparc64's flush_cache_range() flushes every present page in the
>     range from the D-cache;
>  B) sparc64's flush_cache_range() flushes the whole D-cache;
>  C) A for ranges of up to 10 pages, B above that.
> 
> All three pass a test that moves pages between cache colors with
> mremap() and checks for stale data. With no flush at all the same test
> finds about 15 million stale words per run, so it does catch the
> problem.
> 
> Medians of 20 runs over two boots per kernel, against this series'
> move_pte() as the baseline:
> 
>                             move_pte()        A          B          C
>   apt-cache gencaches           6.63 s     +0.2%      +0.3%      +0.1%
>   fork+exec                                +0.7%      +3.1%      -0.6%
>   mremap 8K, same color          14 us      20 us      43 us      20 us
>   mremap 8K, other color         21 us      20 us      43 us      20 us
>   mremap 1M, same color          30 us     524 us      60 us      59 us
>   mremap 8M, same color         209 us    4152 us     229 us     227 us
>   mremap 8M, other color       4176 us    4166 us     236 us     233 us
>   mremap 8M THP, same color      14 us    3933 us      43 us      42 us
> 
> flush_cache_range() has more callers than mremap(), mostly in rmap,
> so I also timed reclaim, migration and writeback (medians of 5):
> 
>                                   A          B          C
>   MADV_PAGEOUT to swap          +0.4%     +12.9%      -1.3%
>   reclaim under memory.max      +1.9%     +17.7%      +2.0%
>   msync of shared file mappings -4.4%      -3.4%      -0.4%
>   compaction, move_pages()      within 3% for all three
> 
> So A pays on large moves, B on reclaim, and C on neither: it costs
> the same as A on small ranges and the same as B on large ones. I'd go
> with C. It would only flush on Spitfire and Cheetah, which have the
> aliasing D-cache, so sun4v and the SPARC64 VII in Magnus's M3000
> series skip it.
> 
> If that works for you, I'd suggest dropping 4/4 and using C as its
> replacement; it's below the scissors, on top of 1/4-3/4.
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.

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

-- 
Cheers,

David