Re: [REGRESSION] mm/mprotect: 2x+ slowdown for >=400KiB regions since PTE batching (cac1db8c3aad)

From: Pedro Falcato

Date: Fri Feb 13 2026 - 11:24:50 EST


On Fri, Feb 13, 2026 at 04:47:29PM +0100, David Hildenbrand (Arm) wrote:
> On 2/13/26 16:08, Luke Yang wrote:
> > Hello,
>
> Hi!
>
> >
> > we have bisected a significant mprotect() performance regression in
> > 6.17-rc1 to:
> >
> > cac1db8c3aad ("mm: optimize mprotect() by PTE batching")
> >
> > The regression becomes clearly visible starting around 400 KiB region
> > sizes and above. It is also still present in the latest 6.19 kernel.
> >
>
> Micro-benchmark results are nice. But what is the real word impact? IOW, why
> should we care?

Well, mprotect is widely used in thread spawning, code JITting,
and even process startup. And we don't want to pay for a feature we can't
even use (on x86).

In any case, I think I see the problem. Namely, that we now need to call
vm_normal_folio() for every single PTE (this seems similar to the mremap
problem caught in 0b5be138ce00f421bd7cc5a226061bd62c4ab850). I'll try to
draft up a patch over the weekend if I can.

--
Pedro