Re: [REGRESSION] mm/mprotect: shared-dirty base-page toggle slower since v6.17

On 22/07/26 4:07 pm, Chengfeng Lin wrote:
> Hi,
> 
> Sorry that my earlier message was difficult to follow.
> 
> The previous exact parent/child test showed that cac1db8c3aad slowed this
> workload by 39.77%. To answer your question directly: no. In a separate
> matched v7.1.3 patch-on/patch-off test, Pedro's full v3 series was 6.20%
> slower than the no-v3 controls, so it did not reduce the slowdown in this
> workload.
> 
> I also checked for an update. The latest public revision I found is still v3,
> and it is already included in Linux v7.1.3.
> 
> To isolate the series, I used the same v7.1.3 source for both kernels. The
> no-v3 kernel replaces only mm/mprotect.c with the exact pre-series file at
> 19999e479c2a. The full-v3 kernel is unmodified v7.1.3 and matches the series
> tip at 89e613bc0b2d. The normalized configs and all other build conditions
> were the same.
> 
> I used a fresh boot for every point:
> 
>   point       mean ns/page
>   no-v3 A          55.333
>   full v3          58.200
>   no-v3 B          54.267
> 
> The no-v3 midpoint was 54.800 ns/page. Full v3 was 6.20% slower than that
> midpoint. The two controls drifted by -1.93%. Dropping the first measured run
> from every point left the v3 delta at +6.18%.
> 
> This was the same narrow standalone workload: a 64 MiB shared anonymous
> mapping, dirty 4 KiB pages, and repeated full-range read-only, restore, and
> write-touch cycles. Each point had 3 warm-up processes and 15 measured
> processes; each measured process ran 1,000 cycles. The benchmark was pinned to
> one P-core with Turbo disabled and preempt=none.
> 
> All 45 measured processes passed the returned-value checks and stayed on 4 KiB
> pages with no THP. The protect and restore phases were each about 23 ns/page
> with v3 and 21 ns/page without v3. The later write-touch phase was unchanged.
> 
> So, for this specific microbenchmark on this machine, Pedro v3 did not reduce
> the slowdown. It produced a small slowdown instead. I am not making a claim
> about other mprotect patterns or application-level performance. My earlier
> QEMU result that suggested a partial improvement should not be used.

I don't see why Pedro's patches should cause a slowdown. The only diff I can think
of is the if (likely(nr_ptes == 1)) check.

But again, we have had these microbench regression discussions before. I think it
is clear by now that vm_normal_folio() is bad on some systems. Best we can do
here IMO is avoid that by doing something like

https://lore.kernel.org/all/[email protected]/

> 
> Thanks,
> Chengfeng
>