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

On Wed, Jul 22, 2026 at 07:24:31PM +0530, Dev Jain wrote:
> 
> 
> 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.

Agree. I don't really understand what this slowdown is about (nor have I had
a proper look, to be fair).

> 
> 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

On my desktop the results were very clear: vm_normal_folio() didn't really
make a difference.

Perhaps we're looking at microarchitectural differences here. I dunno.

-- 
Pedro