On 4/17/20 5:01 AM, Brian Geffon 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. > >>> +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. Thanks, Brian. See my reply to Loresh in just a moment Cheers, Mcihael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/
