Re: [RESEND RFC PATCH 0/5] Remote mapping

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:

quoted

On Fri, Sep 04, 2020 at 02:31:11PM +0300, Adalbert Lazăr wrote:

quoted

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