Re: [RESEND RFC PATCH 0/5] Remote mapping
From: Matthew Wilcox <willy@infradead.org>
Date: 2020-09-04 19:41:51
Also in:
linux-mm
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: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