linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: David Hildenbrand <david@redhat.com>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	Peter Collingbourne <pcc@google.com>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Nadav Amit <nadav.amit@gmail.com>,
	Dave Hansen <dave.hansen@intel.com>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Yang Shi <shy828301@gmail.com>, Hugh Dickins <hughd@google.com>,
	Mel Gorman <mgorman@techsingularity.net>
Subject: Re: [PATCH v3] mm/mprotect: try avoiding write faults for exclusive anonymous pages when changing protection
Date: Wed, 15 Jun 2022 11:25:17 -0400	[thread overview]
Message-ID: <Yqn53TimQq33BanG@xz-m1.local> (raw)
In-Reply-To: <20220614093629.76309-1-david@redhat.com>

On Tue, Jun 14, 2022 at 11:36:29AM +0200, David Hildenbrand wrote:
> Similar to our MM_CP_DIRTY_ACCT handling for shared, writable mappings, we
> can try mapping anonymous pages in a private writable mapping writable if
> they are exclusive, the PTE is already dirty, and no special handling
> applies. Mapping the anonymous page writable is essentially the same thing
> the write fault handler would do in this case.
> 
> Special handling is required for uffd-wp and softdirty tracking, so take
> care of that properly. Also, leave PROT_NONE handling alone for now;
> in the future, we could similarly extend the logic in do_numa_page() or
> use pte_mk_savedwrite() here.
> 
> While this improves mprotect(PROT_READ)+mprotect(PROT_READ|PROT_WRITE)
> performance, it should also be a valuable optimization for uffd-wp, when
> un-protecting.
> 
> This has been previously suggested by Peter Collingbourne in [1],
> relevant in the context of the Scudo memory allocator, before we had
> PageAnonExclusive.
> 
> This commit doesn't add the same handling for PMDs (i.e., anonymous THP,
> anonymous hugetlb); benchmark results from Andrea indicate that there
> are minor performance gains, so it's might still be valuable to streamline
> that logic for all anonymous pages in the future.
> 
> As we now also set MM_CP_DIRTY_ACCT for private mappings, let's rename
> it to MM_CP_TRY_CHANGE_WRITABLE, to make it clearer what's actually
> happening.

I'm personally not sure why DIRTY_ACCT cannot be applied to private
mappings; it sounds not only for shared but a common thing.  I also don't
know whether "change writable" could be misread too anyway. Say, we're
never changing RO->RW mappings with this flag, but only try to unprotect
the page proactively when proper, from that POV Nadav's suggestion seems
slightly better on using "unprotect".

No strong opinion, the patch looks correct to me, and thanks for providing
the new test results,

Acked-by: Peter Xu <peterx@redhat.com>

-- 
Peter Xu



  reply	other threads:[~2022-06-15 15:25 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-14  9:36 David Hildenbrand
2022-06-15 15:25 ` Peter Xu [this message]
2022-06-15 19:52   ` David Hildenbrand
2022-06-15 20:16     ` Peter Xu

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=Yqn53TimQq33BanG@xz-m1.local \
    --to=peterx@redhat.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=dave.hansen@intel.com \
    --cc=david@redhat.com \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mgorman@techsingularity.net \
    --cc=nadav.amit@gmail.com \
    --cc=pcc@google.com \
    --cc=shy828301@gmail.com \
    --cc=torvalds@linux-foundation.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