From: Pedro Falcato <pfalcato@suse.de>
To: "David Hildenbrand (Arm)" <david@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
"Liam R. Howlett" <Liam.Howlett@oracle.com>,
Lorenzo Stoakes <ljs@kernel.org>,
Vlastimil Babka <vbabka@kernel.org>,
Jann Horn <jannh@google.com>, Dev Jain <dev.jain@arm.com>,
Luke Yang <luyang@redhat.com>,
jhladky@redhat.com, linux-mm@kvack.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH 2/4] mm/mprotect: move softleaf code out of the main function
Date: Fri, 20 Mar 2026 10:04:28 +0000 [thread overview]
Message-ID: <ypaiecdbqmma4imr3euccouexs4uecaacjr4aucv4vynz3xbrm@4xa343ivvazy> (raw)
In-Reply-To: <f0ccf41d-16ca-404a-bb84-fe038bcfe0b4@kernel.org>
On Thu, Mar 19, 2026 at 10:33:47PM +0100, David Hildenbrand (Arm) wrote:
> On 3/19/26 19:31, Pedro Falcato wrote:
> > Move softleaf change_pte_range code into a separate function. This makes
> > the change_pte_range() function (or where it inlines) a good bit
> > smaller. Plus it lessens cognitive load when reading through the
> > function.
> >
> > Signed-off-by: Pedro Falcato <pfalcato@suse.de>
> > ---
> > mm/mprotect.c | 128 +++++++++++++++++++++++++++-----------------------
> > 1 file changed, 68 insertions(+), 60 deletions(-)
> >
> > diff --git a/mm/mprotect.c b/mm/mprotect.c
> > index 1bd0d4aa07c2..8d4fa38a8a26 100644
> > --- a/mm/mprotect.c
> > +++ b/mm/mprotect.c
> > @@ -211,6 +211,73 @@ static void set_write_prot_commit_flush_ptes(struct vm_area_struct *vma,
> > commit_anon_folio_batch(vma, folio, page, addr, ptep, oldpte, ptent, nr_ptes, tlb);
> > }
> >
> > +static noinline long change_pte_softleaf(struct vm_area_struct *vma,
>
> Why the noinline? This sounds like something that works good on some
> CPUs and bad on others, no?
>
If you don't like the noinline I can always remove it, but see my other email
for the justification for most code movement here. In this case, I don't see
how softleaf is the common case (at all) and it's a sizeable amount of code.
Note that the results don't show improvement here (in fact, the opposite),
but we are also spinning on the mprotect() system call, so it's hard for
the icache, branch predictors not to be primed.
> I like the cleanup, but the noinline really is odd.
>
> > + unsigned long addr, pte_t *pte, pte_t oldpte, unsigned long cp_flags)
>
> I'd call that "change_softleaf_pte"
>
> > +{
> > + bool uffd_wp = cp_flags & MM_CP_UFFD_WP;
> > + bool uffd_wp_resolve = cp_flags & MM_CP_UFFD_WP_RESOLVE;
>
> both can be const.
ACK, will do!
--
Pedro
next prev parent reply other threads:[~2026-03-20 10:04 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-03-19 18:31 [PATCH 0/4] mm/mprotect: micro-optimization work Pedro Falcato
2026-03-19 18:31 ` [PATCH 1/4] mm/mprotect: encourage inlining with __always_inline Pedro Falcato
2026-03-19 18:59 ` Lorenzo Stoakes (Oracle)
2026-03-19 19:00 ` Lorenzo Stoakes (Oracle)
2026-03-19 21:28 ` David Hildenbrand (Arm)
2026-03-20 9:59 ` Pedro Falcato
2026-03-20 10:08 ` David Hildenbrand (Arm)
2026-03-19 18:31 ` [PATCH 2/4] mm/mprotect: move softleaf code out of the main function Pedro Falcato
2026-03-19 19:06 ` Lorenzo Stoakes (Oracle)
2026-03-19 21:33 ` David Hildenbrand (Arm)
2026-03-20 10:04 ` Pedro Falcato [this message]
2026-03-20 10:07 ` David Hildenbrand (Arm)
2026-03-20 10:54 ` Lorenzo Stoakes (Oracle)
2026-03-19 18:31 ` [PATCH 3/4] mm/mprotect: un-inline folio_pte_batch_flags() Pedro Falcato
2026-03-19 19:14 ` Lorenzo Stoakes (Oracle)
2026-03-19 21:41 ` David Hildenbrand (Arm)
2026-03-20 10:36 ` Lorenzo Stoakes (Oracle)
2026-03-20 10:59 ` Pedro Falcato
2026-03-20 11:02 ` David Hildenbrand (Arm)
2026-03-20 11:27 ` Lorenzo Stoakes (Oracle)
2026-03-20 11:01 ` David Hildenbrand (Arm)
2026-03-20 11:45 ` Lorenzo Stoakes (Oracle)
2026-03-23 12:56 ` David Hildenbrand (Arm)
2026-03-20 10:34 ` Pedro Falcato
2026-03-20 10:51 ` Lorenzo Stoakes (Oracle)
2026-03-19 18:31 ` [PATCH 4/4] mm/mprotect: special-case small folios when applying write permissions Pedro Falcato
2026-03-19 19:17 ` Lorenzo Stoakes (Oracle)
2026-03-20 10:36 ` Pedro Falcato
2026-03-20 10:42 ` Lorenzo Stoakes (Oracle)
2026-03-19 21:43 ` David Hildenbrand (Arm)
2026-03-20 10:37 ` Pedro Falcato
2026-03-20 2:42 ` [PATCH 0/4] mm/mprotect: micro-optimization work Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ypaiecdbqmma4imr3euccouexs4uecaacjr4aucv4vynz3xbrm@4xa343ivvazy \
--to=pfalcato@suse.de \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=david@kernel.org \
--cc=dev.jain@arm.com \
--cc=jannh@google.com \
--cc=jhladky@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ljs@kernel.org \
--cc=luyang@redhat.com \
--cc=vbabka@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox