On Thu, Jan 21, 2021 at 02:13:50PM -0800, Axel Rasmussen wrote: > When I wrote this, my thinking was that users of this feature would > have two mappings, one of which is not UFFD registered at all. So, to > replace the existing page contents, userspace would just write to the > non-UFFD mapping (with memcpy() or whatever else, or we could get > fancy and imagine using some RDMA technology to copy the page over the > network from the live migration source directly in place). After > performing the write, we just UFFDIO_CONTINUE. > > I believe FALLOC_FL_PUNCH_HOLE / MADV_REMOVE doesn't work with > hugetlbfs? Once shmem support is implemented, I would expect > FALLOC_FL_PUNCH_HOLE + UFFDIO_COPY to work, but I wonder if such an > operation would be more expensive than just copying using the other > side of the shared mapping? IIUC hugetlb supports that (hugetlbfs_punch_hole()). But I agree with you on what you said should be good enough. Thanks, -- Peter Xu
