All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Xu <peterx@redhat.com>
To: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Cc: Andrew Morton <akpm@linux-foundation.org>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Axel Rasmussen <axelrasmussen@google.com>,
	Hugh Dickins <hughd@google.com>,
	Nadav Amit <nadav.amit@gmail.com>
Subject: Re: [PATCH] mm/khugepaged: Detecting uffd-wp vma more efficiently
Date: Wed, 22 Sep 2021 15:33:29 -0400	[thread overview]
Message-ID: <YUuFCcuHn74STTlZ@t490s> (raw)
In-Reply-To: <20210922175156.130228-1-peterx@redhat.com>

On Wed, Sep 22, 2021 at 01:51:56PM -0400, Peter Xu wrote:
> Axel: as I asked in the other thread, please help check whether minor mode will
> work properly with shmem thp enabled.  If not, I feel like this patch could be
> part of that effort at last, but it's also possible that I missed something.

Hmm, this seems to be a false-alarm too.

UFFDIO_CONTINUE is fine with thp because shmem_getpage() only returns small
pages.

Khugepaged is fine too on merging small shmem pages into thps, the same reason
as uffd-wp: it zaps ptes only, so previous pte_none() ptes will keep the same,
it makes sure all old pte_none ptes will not continue until a UFFDIO_CONTINUE.

The only last problem is when khugepaged merged small ptes into a thp, then it
could zap ptes even if they existed before.  So for minor mode fault, the uffd
service thread needs to be prepared for false positive messages.

That shouldn't be a problem either, because file-backed memory pgtables are
unstable and prone to lost, so uffd minor fault handler should always be
prepared for false positives anyway..

In summary: please feel free to ignore the above note, and sorry for the noise.

-- 
Peter Xu



  parent reply	other threads:[~2021-09-22 19:33 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-22 17:51 [PATCH] mm/khugepaged: Detecting uffd-wp vma more efficiently Peter Xu
2021-09-22 18:21 ` David Hildenbrand
2021-09-22 18:58   ` Peter Xu
2021-09-22 19:29     ` Yang Shi
2021-09-22 20:04       ` Peter Xu
2021-09-22 20:23         ` Peter Xu
2021-09-24 10:05     ` David Hildenbrand
2021-09-22 19:33 ` Peter Xu [this message]
2021-09-22 20:49 ` Axel Rasmussen
2021-09-22 21:20   ` Peter Xu
2021-09-22 23:18     ` Hugh Dickins
2021-09-22 23:44       ` Peter Xu
2021-09-23  1:22         ` Hugh Dickins
2021-09-23  2:18           ` Peter Xu
2021-09-23 16:47             ` Axel Rasmussen
2021-09-23 17:53               ` 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=YUuFCcuHn74STTlZ@t490s \
    --to=peterx@redhat.com \
    --cc=aarcange@redhat.com \
    --cc=akpm@linux-foundation.org \
    --cc=axelrasmussen@google.com \
    --cc=hughd@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=nadav.amit@gmail.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.