2,257
edits
Changes
Jump to navigation
Jump to search
Line 13:
Line 13: − == <code>parse_smaps</code> ==+ − + + + Line 28:
Line 30: + + + + + + + + + + + + + + − + + + + + + + + + + + + + + + + +
no edit summary
== Dump ==
== Dump ==
Surprisingly, but the mem-drain time is not the biggest. It's "only" ~0.02 seconds. There are places in code that take longer.
Time spent in this routine is about 0.1 seconds on dump. This one exploits /proc heavily. For a container with 11 tasks the syscall stats look like
=== <code>parse_smaps</code> ===
Time spent in this routine is up to 0.2 seconds on dump. This one exploits /proc heavily. For a container with 11 tasks the syscall stats look like
834 read
834 read
11 openat(AT_FDCWD, "/proc/$pid/map_files", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4
11 openat(AT_FDCWD, "/proc/$pid/map_files", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 4
== Restore ==
=== Fork vs VMA restore ===
We restore task's mappings before it goes forking to handle COW. This effectively serializes forking.
=== Restoring VMAs ===
There are 4 stages in VMA restore. Relative times of each are below
* Reading images 1%
* Mapping huuge premap area << 1%
* (Re-)mapping sub-areas 73%
* Filling area with data 26%
== Restore ==
The 3rd stage has two parts. With timings:
* Opening filemap fd 85%
* Maping vma 15%
=== Opening files for mappings ===
The <code>get_filemap_fd()</code> opens new fd every time. If a file is mapped several
times (e.g. -- a library) we can share one fd for that.
=== Staging ===
When restoring a single task CRIU uses [[stages of restoring]] which slows things down. Need either special-care the single task restore, or introduce fine-grained locking for such things.
[[Category: Development]]
[[Category: Thinkers]]