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

[Dev Jain]

On 21/07/26 6:09 pm, Chengfeng Lin wrote:
> 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().
> 

Sorry it is difficult for me to parse your report. So I didn't understand whether
Pedro's patches helped you or not?


> Thanks,
> Chengfeng