41
edits
Changes
Jump to navigation
Jump to search
Line 166:
Line 166: + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
→Project ideas: COW pages dump optimization
* [1] LUO kernel documentation https://docs.kernel.org/core-api/liveupdate.html
* [1] LUO kernel documentation https://docs.kernel.org/core-api/liveupdate.html
* [2] LUO memfd doc https://docs.kernel.org/mm/memfd_preservation.html
* [2] LUO memfd doc https://docs.kernel.org/mm/memfd_preservation.html
'''Details:'''
* Skill level: intermediate / advanced
* Language: C
* Expected size: 350 hours
* Suggested by: Andrei Vagin <avagin@gmail.com>
* Mentors: Andrei Vagin <avagin@gmail.com>, Alexander Mikhalitsyn <alexander@mihalicyn.com>
=== Optimize COW memory dumping ===
'''Summary:''' Optimize COW memory dumping
The Linux kernel memory management subsystem is highly optimized not only for performance, but also to minimize unnecessary memory consumption. A key example of this is how the kernel handles private VMAs when user space invokes the fork() system call.
Rather than duplicating the entire VMA tree along with all memory contents, the kernel creates optimized copies of inherited VMAs using the Copy-on-Write (COW) mechanism. When a process writes to a page within a COW-ed VMA, a write page fault occurs, and the kernel creates a private copy of that page before applying the modification. However, if the page is only read, no copying is performed.
This approach significantly improves fork() performance and can dramatically reduce memory usage in many workloads.
In CRIU, when dumping VMAs and their associated memory pages, this COW optimization is not currently taken into account during the dump phase. As a result, for COW-backed VMAs, CRIU may generate multiple copies of identical memory pages in the dump image.
During restore, however, CRIU explicitly handles this situation (see [1] and [2]) and attempts to reconstruct COW relationships inside the kernel. This step is critical: without it, a checkpoint/restore (C/R) cycle could lead to a substantial increase in memory consumption for the same process tree. For example, a workload that originally consumed 500 MiB could expand to 800 MiB after restore, which is clearly unacceptable.
This project aims to improve the dumping algorithm so that it avoids producing multiple unnecessary copies of identical pages belonging to COW-ed VMAs.
The project requires some understanding of Linux memory management internals and CRIU’s architecture. We strongly encourage GSoC contributors to study references [1] and [2] and experiment with the relevant code paths before applying. We are happy to answer questions and provide guidance along the way.
'''Links:'''
* [1] preparing COW VMAs https://github.com/checkpoint-restore/criu/blob/c180188db036f8ea4c08bfee28cbcdbdd52cdfc3/criu/mem.c#L878
* [2] private vma content restore cow case https://github.com/checkpoint-restore/criu/blob/c180188db036f8ea4c08bfee28cbcdbdd52cdfc3/criu/mem.c#L1219
'''Details:'''
'''Details:'''