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 I found some interest in this project here, with the detail that pin_user_pages() should keep working, ideally on both sides of the share, but essentially on the side that calls mshare() Maybe we can help out, at least cc me if you make progress :) Thanks, Jason
