On Fri, Sep 04, 2020 at 09:11:48AM -0300, Jason Gunthorpe wrote: > On Fri, Sep 04, 2020 at 02:31:11PM +0300, Adalbert Lazăr wrote: > > VMAs obtained by mmap()ing memory access fds mirror the contents of the remote > > process address space within the specified range. Pages are installed in the > > current process page tables at fault time and removed by the mmu_interval_notifier > > invalidate callbck. No further memory management is involved. > > On attempts to access a hole, or if a mapping was removed by PIDFD_MEM_UNMAP, > > or if the remote process address space was reaped by OOM, the remote mapping > > fault handler returns VM_FAULT_SIGBUS. > > I still think anything along these lines needs to meet the XPMEM use > cases as well, we have to have more general solutions for such MM > stuff: > > https://gitlab.com/hjelmn/xpmem > > However, I think this fundamentally falls into some of the same bad > direction as xpmem. > > I would much rather see this design copy & clone the VMA's than try to > mirror the PTEs inside the VMAs from the remote into a single giant > VMA and somehow split/mirror the VMA ops. I'm on holiday for the next few days, but does the mshare() API work for your use case? Proposal: http://www.wil.cx/~willy/linux/sileby.html Start at implementation: http://git.infradead.org/users/willy/linux.git/shortlog/refs/heads/mshare
