[CRIU] GSoC: Boot up week

[Radostin Stoyanov]

Hi Abhishek,

I have some suggestions/ideas that may be useful.

On 22/05/2019 01:11, Abhishek Dubey wrote:
> Hi Pavel,
>
> I have gone through the cr_pre_dump_tasks() function tree and quite 
> comfortable with parts of it. Compel stuff seem bit difficult to 
> digest in one go.
> I will query if stuck somewhere in code. I think we can start with 
> design discussion.
>
> Some queries related to new approach:
> 1) We need to replace page pipe with user-space supplied buffer. There 
> is list of pipes in struct page_pipe. If I got it correct then, pipe 
> buffer in the list has to be replaced with user-supplied buffer and 
> these buffer exhibit same properties as of pipes in current 
> implementation?
>
There is a prototype implementation which you can use as a starting point:

https://github.com/avagin/criu/tree/process_vm_readv

> 2) We finalized user space buffer for process_vm_readv to be of fixed 
> size. How do we go deciding best size (=max size of pipe)?

Currently, CRIU is creating a pipe and it is continuously increasing 
it's buffer size (see __ppb_resize_pipe() in criu/page-pipe.c). In the 
case of pre-dump (or when --leave-running is used) it would be more 
efficient to compute the necessary memory space and allocate it prior 
freezing the process tree. Thus, reducing the down time during pre-copy 
migration.

Dump is currently using chunks (see commit bb98a82) and perhaps the same 
idea could be applied with memory buffer(s). This reduces the required 
amount of memory during checkpoint (e.g. when we want to dump a process 
tree that occupies 90% of the available memory).

>
> 3) iovs generation for shared mapping are ignored and shared mapping 
> is handled separately. Will new approach handle shared memory similarly?
>
> 4) Freeze - collect vmas - Unfreeze : How we go about handling 
> following events -
>          a) process does something such that vma gets modified
>               - we can't ignore such mappings
>               - we can't freeze single process again, becomes 
> inconsistent with other tree processes
>          b) one of the process in pstree dies
>
> - Abhishek
>
> On Wed, May 15, 2019 at 1:15 PM Pavel Emelianov <xemul at virtuozzo.com 
> <mailto:xemul at virtuozzo.com>> wrote:
>
>     On 5/14/19 9:08 PM, Abhishek Dubey wrote:
>     > Hi,
>     >
>     > I have tried suggested way of running zdtm test suite and played
>     with CRIT. I am going through cr_pre_dump_tasks() function-tree.
>     Please point out, if I must know any other necessary piece of code.
>     >
>     > I have used process_vm_readv() to copy pages, listed by parsing
>     /proc/PID/maps of target process (a simple process that does mmap)
>     and made following observations :
>     > 1) A memory region could be read from target process only if
>     read access is set.
>
>     Of course, that's why there's a call to PARASITE_CMD_MPROTECT_VMAS
>     in parasite_dump_pages_seized.
>     We should just skip those mappnigs for the new approach.
>
>     > 2) [vvar] region turned out to be one of unreadable region,
>     although read permission is set. Are there more such unreadable
>     regions expected?
>
>     There's a generate_vma_iovs  call that checks if we should try to
>     dump the vma in question at all.
>     If I'm not mistaken, it should skip all the "bad" vmas for you.
>
>     -- Pavel
>
>
> _______________________________________________
> CRIU mailing list
> CRIU at openvz.org
> https://lists.openvz.org/mailman/listinfo/criu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20190522/3c3aeb91/attachment-0001.html>