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

[Chengfeng Lin]

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.

Thanks,
Chengfeng