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
Reply to
Jason Gunthorpe, 2020-09-04
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
Thread (40 messages) 40 messages, 12 authors, last reply 2020-12-01
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help