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

[Suren Baghdasaryan <surenb@google.com>]

On Fri, Feb 13, 2026 at 4:24 PM Pedro Falcato <pfalcato@suse.de> wrote:
>
> 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).

I agree. When I straced Android's zygote a while ago, mprotect() came
up #30 in the list of most frequently used syscalls and one of the
most used mm-related syscalls due to its use during process creation.
However, I don't know how often it's used on VMAs of size >=400KiB.

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