All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: Kefeng Wang <wangkefeng.wang@huawei.com>
Cc: Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org
Subject: Re: [PATCH] mm: memory: check userfaultfd_wp() in vmf_orig_pte_uffd_wp()
Date: Wed, 17 Apr 2024 14:34:27 -0400	[thread overview]
Message-ID: <ZiAWM54rOXxvYWfd@x1n> (raw)
In-Reply-To: <b6381f7b-4c0b-474a-82e4-7502d0811175@huawei.com>

Hi, Kefeng,

On Wed, Apr 17, 2024 at 05:30:40PM +0800, Kefeng Wang wrote:
> 
> 
> On 2024/4/17 16:23, Kefeng Wang wrote:
> > Directly call vmf_orig_pte_uffd_wp() in do_anonymous_page() and
> > set_pte_range() to save a uffd_wp and add userfaultfd_wp() check
> > in vmf_orig_pte_uffd_wp() to avoid the unnecessary function calls
> > in the most sense, lat_pagefault testcase does show improvement
> > though very small(~1%).

I'm ok with the change if that helps as big as 1%, but I'm a bit surprised
to see such a difference, because for file pte_marker_uffd_wp() should
check first on pte_none() then it should return already if uffd not even
registered for the vma, while orig_pte should be hot too if valid.

> > 
> > Signed-off-by: Kefeng Wang <wangkefeng.wang@huawei.com>
> > ---
> >   mm/memory.c | 9 +++++----
> >   1 file changed, 5 insertions(+), 4 deletions(-)
> > 
> > diff --git a/mm/memory.c b/mm/memory.c
> > index 5ae2409d3cb9..a6afc96001e6 100644
> > --- a/mm/memory.c
> > +++ b/mm/memory.c
> > @@ -117,6 +117,9 @@ static bool vmf_orig_pte_uffd_wp(struct vm_fault *vmf)
> 
> 
> 	 if (!IS_ENABLED(CONFIG_PTE_MARKER_UFFD_WP))
>         	return false;
> 
> Will add config check too,

pte_marker_uffd_wp() returns false when !PTE_MARKER_UFFD_WP, so kind of
imply this.  I assume you meant to avoid checking ORIG_PTE_VALID flag, but
the flags is pretty hot too.  Again, just want to double check with you on
whether it can have such a huge difference, e.g., how that compares with
the current code v.s. original patch v.s. this squashed.

Thanks,

> 
> >   	if (!(vmf->flags & FAULT_FLAG_ORIG_PTE_VALID))
> >   		return false;
> > +	if (!userfaultfd_wp(vmf->vma))
> > +		return false;
> > +
> 
> but wait for review.
> 
> >   	return pte_marker_uffd_wp(vmf->orig_pte);
> >   }
> > @@ -4388,7 +4391,6 @@ static struct folio *alloc_anon_folio(struct vm_fault *vmf)
> >    */
> >   static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
> >   {
> > -	bool uffd_wp = vmf_orig_pte_uffd_wp(vmf);
> >   	struct vm_area_struct *vma = vmf->vma;
> >   	unsigned long addr = vmf->address;
> >   	struct folio *folio;
> > @@ -4488,7 +4490,7 @@ static vm_fault_t do_anonymous_page(struct vm_fault *vmf)
> >   	folio_add_new_anon_rmap(folio, vma, addr);
> >   	folio_add_lru_vma(folio, vma);
> >   setpte:
> > -	if (uffd_wp)
> > +	if (vmf_orig_pte_uffd_wp(vmf))
> >   		entry = pte_mkuffd_wp(entry);
> >   	set_ptes(vma->vm_mm, addr, vmf->pte, entry, nr_pages);
> > @@ -4663,7 +4665,6 @@ void set_pte_range(struct vm_fault *vmf, struct folio *folio,
> >   		struct page *page, unsigned int nr, unsigned long addr)
> >   {
> >   	struct vm_area_struct *vma = vmf->vma;
> > -	bool uffd_wp = vmf_orig_pte_uffd_wp(vmf);
> >   	bool write = vmf->flags & FAULT_FLAG_WRITE;
> >   	bool prefault = in_range(vmf->address, addr, nr * PAGE_SIZE);
> >   	pte_t entry;
> > @@ -4678,7 +4679,7 @@ void set_pte_range(struct vm_fault *vmf, struct folio *folio,
> >   	if (write)
> >   		entry = maybe_mkwrite(pte_mkdirty(entry), vma);
> > -	if (unlikely(uffd_wp))
> > +	if (unlikely(vmf_orig_pte_uffd_wp(vmf)))
> >   		entry = pte_mkuffd_wp(entry);
> >   	/* copy-on-write page */
> >   	if (write && !(vma->vm_flags & VM_SHARED)) {
> 

-- 
Peter Xu



  reply	other threads:[~2024-04-17 18:34 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-17  8:23 [PATCH] mm: memory: check userfaultfd_wp() in vmf_orig_pte_uffd_wp() Kefeng Wang
2024-04-17  9:30 ` Kefeng Wang
2024-04-17 18:34   ` Peter Xu [this message]
2024-04-18  1:47     ` Kefeng Wang
2024-04-18 10:44       ` Kefeng Wang

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=ZiAWM54rOXxvYWfd@x1n \
    --to=peterx@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=linux-mm@kvack.org \
    --cc=wangkefeng.wang@huawei.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.