From: David Hildenbrand <david@redhat.com>
To: Peter Xu <peterx@redhat.com>, Suren Baghdasaryan <surenb@google.com>
Cc: Lokesh Gidra <lokeshgidra@google.com>,
Jann Horn <jannh@google.com>,
akpm@linux-foundation.org, viro@zeniv.linux.org.uk,
brauner@kernel.org, shuah@kernel.org, aarcange@redhat.com,
hughd@google.com, mhocko@suse.com, axelrasmussen@google.com,
rppt@kernel.org, willy@infradead.org, Liam.Howlett@oracle.com,
zhangpeng362@huawei.com, bgeffon@google.com,
kaleshsingh@google.com, ngeoffray@google.com, jdduke@google.com,
linux-mm@kvack.org, linux-fsdevel@vger.kernel.org,
linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
kernel-team@android.com
Subject: Re: [PATCH v2 2/3] userfaultfd: UFFDIO_REMAP uABI
Date: Tue, 3 Oct 2023 23:08:07 +0200 [thread overview]
Message-ID: <c837fc02-3dbd-ba88-dacb-cf150272a4c4@redhat.com> (raw)
In-Reply-To: <ZRx31TKFDGRatoC8@x1n>
On 03.10.23 22:21, Peter Xu wrote:
> On Tue, Oct 03, 2023 at 01:04:44PM -0700, Suren Baghdasaryan wrote:
>> Ok, I think it makes sense to implement the strict remap logic but in
>> a way that we can easily add copy fallback if that's needed in the
>> future. So, I'll change UFFDIO_REMAP to UFFDIO_MOVE and will return
>> some unique error, like EBUSY when the page is not PAE. If we need to
>> add a copy fallback in the future, we will add a
>> UFFDIO_MOVE_MODE_ALLOW_COPY flag and will implement the copy
>> mechanism. Does that sound good?
>
> For the clear failing approach, sounds all good here.
>
> For the name, no strong opinion, but is there any strong one over MOVE?
See my reply regarding MOVE (+zero-copy optimization) vs. REMAP. Just my
thoughts.
REMAP reminds me of mremap, which would never perform any copies,
because it can just do more expensive page remappings (modifying VMAs etc.).
> MOVE is a fine name, however considering UFFDIO_REMAP's long history.. I
> tend to prefer keeping it called as REMAP - it still sounds sane, and
> anyone who knows REMAP will know this is exactly that.
Sorry I have to ask: has this ever been discussed on the list? I don't
see any pointers. If not, then probably the number of people that know
about the history can be counted with my two hands and that shouldn't be
the basis for making decisions.
But again, remap vs. move is for me a semantical difference; and as I am
not a native speaker others might disagree and I might be just wrong.
--
Cheers,
David / dhildenb
next prev parent reply other threads:[~2023-10-03 21:08 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-23 1:31 [PATCH v2 0/3] userfaultfd remap option Suren Baghdasaryan
2023-09-23 1:31 ` [PATCH v2 1/3] userfaultfd: UFFDIO_REMAP: rmap preparation Suren Baghdasaryan
2023-09-28 16:23 ` Peter Xu
2023-09-28 20:03 ` Suren Baghdasaryan
2023-10-02 14:42 ` David Hildenbrand
2023-10-02 15:23 ` Peter Xu
2023-10-02 17:30 ` David Hildenbrand
2023-10-03 17:56 ` Suren Baghdasaryan
2023-09-23 1:31 ` [PATCH v2 2/3] userfaultfd: UFFDIO_REMAP uABI Suren Baghdasaryan
2023-09-27 10:06 ` potential new userfaultfd vs khugepaged conflict [was: Re: [PATCH v2 2/3] userfaultfd: UFFDIO_REMAP uABI] Jann Horn
2023-09-27 17:12 ` Suren Baghdasaryan
2023-09-28 15:29 ` Jann Horn
2023-09-27 12:47 ` [PATCH v2 2/3] userfaultfd: UFFDIO_REMAP uABI Jann Horn
2023-09-27 13:29 ` David Hildenbrand
2023-09-27 18:25 ` Suren Baghdasaryan
2023-09-28 16:28 ` Peter Xu
2023-09-28 17:15 ` David Hildenbrand
2023-09-28 18:32 ` Suren Baghdasaryan
2023-09-28 20:11 ` Suren Baghdasaryan
2023-09-28 19:00 ` Peter Xu
2023-10-02 7:49 ` David Hildenbrand
2023-09-28 16:24 ` Peter Xu
2023-09-28 17:05 ` David Hildenbrand
2023-09-28 17:21 ` Peter Xu
2023-09-28 17:51 ` David Hildenbrand
2023-09-28 18:34 ` Peter Xu
2023-09-28 19:47 ` Suren Baghdasaryan
2023-10-02 8:00 ` David Hildenbrand
2023-10-02 15:21 ` Peter Xu
2023-10-02 15:46 ` Lokesh Gidra
2023-10-02 15:55 ` Lokesh Gidra
2023-10-02 17:43 ` David Hildenbrand
2023-10-02 19:33 ` Lokesh Gidra
2023-10-03 20:04 ` Suren Baghdasaryan
2023-10-03 20:21 ` Peter Xu
2023-10-03 21:08 ` David Hildenbrand [this message]
2023-10-03 21:20 ` Peter Xu
2023-10-03 22:26 ` Suren Baghdasaryan
2023-10-03 23:39 ` Lokesh Gidra
2023-10-06 12:30 ` David Hildenbrand
2023-10-06 15:02 ` Suren Baghdasaryan
2023-10-03 21:04 ` David Hildenbrand
2023-10-02 17:33 ` David Hildenbrand
2023-10-02 17:36 ` David Hildenbrand
2023-09-27 18:07 ` Suren Baghdasaryan
2023-09-27 20:04 ` Jann Horn
2023-09-27 20:42 ` Suren Baghdasaryan
2023-09-27 21:08 ` Suren Baghdasaryan
2023-09-27 22:48 ` Jann Horn
2023-09-28 15:36 ` Suren Baghdasaryan
2023-09-28 17:09 ` Peter Xu
2023-09-28 18:23 ` Suren Baghdasaryan
2023-09-28 18:43 ` Peter Xu
2023-09-28 19:50 ` Suren Baghdasaryan
2023-09-23 1:31 ` [PATCH v2 3/3] selftests/mm: add UFFDIO_REMAP ioctl test Suren Baghdasaryan
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=c837fc02-3dbd-ba88-dacb-cf150272a4c4@redhat.com \
--to=david@redhat.com \
--cc=Liam.Howlett@oracle.com \
--cc=aarcange@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=axelrasmussen@google.com \
--cc=bgeffon@google.com \
--cc=brauner@kernel.org \
--cc=hughd@google.com \
--cc=jannh@google.com \
--cc=jdduke@google.com \
--cc=kaleshsingh@google.com \
--cc=kernel-team@android.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=lokeshgidra@google.com \
--cc=mhocko@suse.com \
--cc=ngeoffray@google.com \
--cc=peterx@redhat.com \
--cc=rppt@kernel.org \
--cc=shuah@kernel.org \
--cc=surenb@google.com \
--cc=viro@zeniv.linux.org.uk \
--cc=willy@infradead.org \
--cc=zhangpeng362@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).