Thread (40 messages) flat view 40 messages, 12 authors, 2020-12-01

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

From: Jason Gunthorpe <jgg@ziepe.ca>
Date: 2020-09-04 12:11:52
Also in: linux-mm

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.

This is just too weird and fragile to be maintaible over a long
term.

For instance, one of the major bugs in things like xpmem was that they
are incompatible with get_user_pages(), largely because of this issue.

I feel like I said this already..

Jason
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help