Re: [PATCH v2] mremap.2: Add information for MREMAP_DONTUNMAP.

From: Lokesh Gidra <lokeshgidra@google.com>
To: Brian Geffon <bgeffon@google.com>
Cc: "Michael Kerrisk (man-pages)" <mtk.manpages@gmail.com>,
	linux-man@vger.kernel.org, Sonny Rao <sonnyrao@google.com>,
	Jesse Barnes <jsbarnes@google.com>,
	Vlastimil Babka <vbabka@suse.cz>,
	Minchan Kim <minchan@kernel.org>,
	"Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Subject: Re: [PATCH v2] mremap.2: Add information for MREMAP_DONTUNMAP.
Date: Tue, 21 Apr 2020 17:15:43 -0700	[thread overview]
Message-ID: <CA+EESO6ODSQV4QA0-ZpyvmHb2395Gutt0ac5uBYNyTdWKdSY1Q@mail.gmail.com> (raw)
In-Reply-To: <CADyq12xA69pSZ=JfMuG_c8T1UHepmdSqBwLLPgFrOyXeveVk4w@mail.gmail.com>

On Thu, Apr 16, 2020 at 8:02 PM Brian Geffon <bgeffon@google.com> wrote:
>
> Hi Michael,
>
> > Thanks for this patch. I've applied it, and done quite a
> > bit of editing. Could you please take a look at the
> > version in Git, and let me know if I made any bad changes
> > to your text.
>
> Your changes look good.
>
> > You write "move", but would it not be more correcrt to say something
> > like "duplicate"?
>
> It's a little of both, it duplicates the VMA but moves the page table
> entries. So the behavior feels more like a move followed by a new
> mapping created that had the same properties as the previous. Does
> that make sense?
>
> > > +Possible applications for this behavior might be garbage collection or
> >
> > Can you elaborate the garbage collection use case a little, please?
>
> Lokesh, who is CCed, can probably expand better than I can, Lokesh
> would you mind elaborating on how the JVM plans to use this.
>
There are many GC algorithms in literature which use PROT_NONE+SIGSEGV
trick to implement concurrent compaction of java heap. In Android
Runtime we plan to use userfaultfd instead. But this requires a
stop-the-world, wherein Java threads are paused, right before starting
the compaction phase. Within this pause, the physical pages in the
Java heap will be moved to another area, so that the Java heap, which
is already registered with userfaultfd, can start 'userfaulting' (as
Java heap pages are missing) once application threads are resumed.

In the absence of MREMAP_DONTUNMAP, I'd have to do it by first doing
mremap, and then mmaping Java heap, as its virtual mapping would be
removed by the preceding mremap. This not only causes performance
issues as two system calls need to be made instead of one, but it also
leaves a window open for a native thread, which is not paused, to
create a virtual mapping for its own usage right where Java heap is
supposed to be.

> > > +non-cooperative
> > > +.BR userfaultfd (2) .
> >
> > What is noncooperative userfaultfd(2)?
>
> No cooperative userfaultfd is the term that people tend to use when
> the threads accessing the memory are not cooperating with the fault
> handling, MREMAP_DONTUNMAP is interesting for this as you can yank out
> the page tables from a running process and immediately start handling
> faults for the registered range without having to stop the process.
>
> I hope that answers your questions, feel free to ask if you need more
> clarification.
>
> Brian