332
edits
Changes
Created page with "This page lists accepted projects that were completed during [https://summerofcode.withgoogle.com Google Summer of Code 2019]. For the list of ideas go Google Summer of Code..."
This page lists accepted projects that were completed during [https://summerofcode.withgoogle.com Google Summer of Code 2019]. For the list of ideas go [[Google Summer of Code Ideas|here]].
==Student final submissions==
=== Abhishek Dubey - Optimize the pre-dump algorithm ===
'''Final report''': https://dubeyabhishek.github.io/GSoC19CRIU/
'''Summary:''' Optimize the pre-dump algorithm to avoid pinning to many memory in RAM
Current [[CLI/cmd/pre-dump|pre-dump]] mode is used to write task memory contents into image
files w/o stopping the task for too long. It does this by stopping the task, infecting it and
draining all the memory into a set of pipes. Then the task is cured, resumed and the pipes'
contents is written into images (maybe a [[page server]]). Unfortunately, this approach creates
a big stress on the memory subsystem, as keeping all memory in pipes creates a lot of unreclaimable
memory (pages in pipes are not swappable), as well as the number of pipes themselves can be huge, as
one pipe doesn't store more than a fixed amount of data (see pipe(7) man page).
A solution for this problem is to use a sys_read_process_vm() syscall, which will mitigate
all of the above. To do this we need to allocate a temporary buffer in criu, then walk the
target process vm by copying the memory piece-by-piece into it, then flush the data into image
(or page server), and repeat.
Ideally there should be sys_splice_process_vm() syscall in the kernel, that does the same as
the read_process_vm does, but vmsplices the data
'''Links:'''
* [[Memory pre dump]]
* https://github.com/checkpoint-restore/criu/issues/351
* [[Memory dumping and restoring]], [[Memory changes tracking]]
* [http://man7.org/linux/man-pages/man2/process_vm_readv.2.html process_vm_readv(2)] [http://man7.org/linux/man-pages/man2/vmsplice.2.html vmsplice(2)] [https://lkml.org/lkml/2018/1/9/32 RFC for splice_process_vm syscall]
'''Details:'''
* Skill level: advanced
* Language: C
* Mentor: Pavel Emelianov <xemul@virtuozzo.com>
* Suggested by: Pavel Emelianov <xemul@virtuozzo.com>
[[Category:GSoC]]
==Student final submissions==
=== Abhishek Dubey - Optimize the pre-dump algorithm ===
'''Final report''': https://dubeyabhishek.github.io/GSoC19CRIU/
'''Summary:''' Optimize the pre-dump algorithm to avoid pinning to many memory in RAM
Current [[CLI/cmd/pre-dump|pre-dump]] mode is used to write task memory contents into image
files w/o stopping the task for too long. It does this by stopping the task, infecting it and
draining all the memory into a set of pipes. Then the task is cured, resumed and the pipes'
contents is written into images (maybe a [[page server]]). Unfortunately, this approach creates
a big stress on the memory subsystem, as keeping all memory in pipes creates a lot of unreclaimable
memory (pages in pipes are not swappable), as well as the number of pipes themselves can be huge, as
one pipe doesn't store more than a fixed amount of data (see pipe(7) man page).
A solution for this problem is to use a sys_read_process_vm() syscall, which will mitigate
all of the above. To do this we need to allocate a temporary buffer in criu, then walk the
target process vm by copying the memory piece-by-piece into it, then flush the data into image
(or page server), and repeat.
Ideally there should be sys_splice_process_vm() syscall in the kernel, that does the same as
the read_process_vm does, but vmsplices the data
'''Links:'''
* [[Memory pre dump]]
* https://github.com/checkpoint-restore/criu/issues/351
* [[Memory dumping and restoring]], [[Memory changes tracking]]
* [http://man7.org/linux/man-pages/man2/process_vm_readv.2.html process_vm_readv(2)] [http://man7.org/linux/man-pages/man2/vmsplice.2.html vmsplice(2)] [https://lkml.org/lkml/2018/1/9/32 RFC for splice_process_vm syscall]
'''Details:'''
* Skill level: advanced
* Language: C
* Mentor: Pavel Emelianov <xemul@virtuozzo.com>
* Suggested by: Pavel Emelianov <xemul@virtuozzo.com>
[[Category:GSoC]]