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

[Chengfeng Lin]

Hi,

Just a gentle ping, with results from an exact commit-level check.

I tested cac1db8c3aad ("mm: optimize mprotect() by PTE batching")
against its direct parent 45199f715b74. Each point used a fresh boot:

  45199f715b74 parent A -> cac1db8c3aad child ->
  45199f715b74 parent B

I used the same narrow 64 MiB shared-dirty 4 KiB base-page toggle
workload from the report. Each point had 3 warm-up processes and
15 measured processes. Each measured process ran 1,000 iterations.
The primary result, iteration_ns_per_page (lower is better), was:

  point       mean ns/page    SD
  parent A          38.133  0.743
  child             53.533  0.516
  parent B          38.467  0.640

The parent midpoint was 38.300 ns/page. The child was 39.77% slower,
while parent B differed from parent A by only 0.87%. Dropping the first
measured process from every point left a 39.53% child delta.

All 45 measured processes passed the semantic checks and used 4 KiB
pages with no THP. The protect and restore components each increased
from 13 ns/page in the parent controls to 20 ns/page in the child.
The post-touch component stayed close to 12 ns/page.

The exact commit changes only mm/mprotect.c. Both kernels were built from
the exact commits with the same normalized config, GCC 15.2.0, and Kbuild
metadata. Every point used the same CPU settings and runtime preempt=none.

For this narrow workload, the exact parent/child result identifies
cac1db8c3aad as the source of the measured slowdown. I am not claiming
a generic mprotect() or application-level regression.

Evidence:

  https://github.com/lcf0399/linux-regression-evidence/tree/a3ae7bf1a50e4d88b572c6005a037679530c9b1f/mprotect-shared-dirty-toggle/bare-metal/20260721-cac1db8c3aad-exact-ab

#regzbot introduced: cac1db8c3aad97d6ffb56ced8868d6cbbbd2bfbe

If useful, I can still collect a perf profile of the child around
change_pte_range().

Thanks,
Chengfeng