On Fri, Sep 04, 2020 at 08:41:39PM +0100, Matthew Wilcox wrote: > 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 Let me ask around, it seems in a similar space at least! Thanks, Jason
