On 04.10.23 01:39, Lokesh Gidra wrote:
On Tue, Oct 3, 2023 at 11:26 PM Suren Baghdasaryan surenb@google.com wrote:
On Tue, Oct 3, 2023 at 2:21 PM Peter Xu peterx@redhat.com wrote:
On Tue, Oct 03, 2023 at 11:08:07PM +0200, David Hildenbrand wrote:
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.
For example:
https://lore.kernel.org/all/1425575884-2574-21-git-send-email-aarcange@redha...
Sorry, I had to process a family NMI the last couple of days.
There was another submission in 2019: https://lore.kernel.org/all/cover.1547251023.git.blake.caldwell@colorado.edu...
It would be good to link them in the cover letter and shortly explain why that wasn't merged back then (if there was any reason).
Though both times it did not generate much discussion. I don't have a strong preference though MOVE sounds more generic to me TBH (it specifies the operation rather than REMAP which hints on how that operation is carried out). But again, I'm fine either way.
That's a good point. IMHO, if in future we want to have the fallback implemented, then MOVE would be a more appropriate name than REMAP.
As for UFFDIO_MOVE_ZERO_COPY_ONLY vs UFFDIO_MOVE_MODE_ALLOW_COPY, I find it weird that the default (the most efficient/desired) mode of operation needs a flag. I would prefer to have no flag initially and add UFFDIO_MOVE_MODE_ALLOW_COPY or whatever name is more appropriate when/if we ever need it. Makes sense?
Agreed!
I agree. One could have UFFDIO_MOVE that is best-effort and documented like that, and a to-be-named future extension that always works but might be more expensive.
Ideally we'd have an interface that does not expose and/or rely on such low-level information and simply always works, but getting that would mean that we'd have to implement the fallback immediately ... so I guess we'll have to expose a best-effort interface first.