[CRIU] [PATCH RFC 2/8] criu: page_pipe_buf: add PPB_LAZY flag

[Adrian Reber]

On Sun, May 29, 2016 at 09:46:54AM +0300, Mike Rapoport wrote:
> On Fri, May 27, 2016 at 10:26:53PM +0300, Pavel Emelyanov wrote:
> > On 05/21/2016 01:49 PM, Mike Rapoport wrote:
> > > for buffers that contain potentially lazy pages
> > 
> > But... Why a buffer would contain lazy pages?
> 
> The pages of the dumpee should be somewhere. One option is to skip these
> pages when parasite is doing vmsplice from the dumpee memory to the
> buffers, keep parasite in the dumpee and make it capable of handling random
> memory accesses when a page fault occurs at the restore side.
> I've chosen to vmsplice everything and just add a flag that will
> differentiate between the buffers that should be written to the image files
> (e.g VDSO) and the buffers that contain pages that would be transferred
> over the network, i.e. ANONYMOUS | PRIVATE. The page_xfer_dump_pages will
> skip the PPB_LAZY buffers when writing pages-*.img, and when the restore
> will request a lazy page, it will be extracted from the PPB_LAZY buffer and
> sent over the network.
> 
> Probably I should have explained in more detail what's going on at the
> first place, but better later than never. So, in a nutshell, this
> implementation of remote lazy pages does the following:
> 
> * dump collects the process memory into the pipes and continues without
> transferring the memory into images or to the page-server at the restore
> size (pretty much like pre-dump action).
> * when the dump creates the page_pipe_bufs, it marks the buffers containing
> potentially lazy pages with PPB_LAZY
> * at the dump_finish stage, the dump side starts TCP server that will
> handle page requests from the restore side
> * the checkpoint directory is transferred to the restore side
> * on the restore side lazy-pages daemon is started, it creates UNIX socket
> to receive uffd's from the restore and a TCP socket to forward page
> requests to the dump side
> * restore creates memory mappings and fills the VMAs that cannot be handled
> by uffd with the contents of the pages*img.
> * restore registers lazy VMAs with uffd and sends the userfault file
> descriptors to the lazy-pages daemon
> * when a #PF occurs, the lazy-pages daemon sends PS_IOV_GET command to the dump
> side; the command contains PID, the faulting address and amount of pages
> (always 1 at the moment)
> * the dump side extracts the requested pages from the pipe and splices them
> into the TCP socket.
> * the lazy-pages daemon copies the received pages into the restored process
> address space

I like this description. This should be part of the commit message.

		Adrian