xemul / criu

64%

master: 66%

LAST BUILD ON BRANCH criu-dev-rst-mem-2

branch: criu-dev-rst-mem-2

CHANGE BRANCH

x

Reset

• criu-dev-rst-mem-2
• HEAD
• br-criu-dev-fpregs-arch
• br-issue-302
• criu-2.x-stable
• criu-compel
• criu-dev
• criu-dev-fdinfo-parse-once
• criu-dev-filemap-open-fix
• criu-dev-files-image-merge
• criu-dev-files-images
• criu-dev-fsnotify
• criu-dev-ghost-holes
• criu-dev-init-relax
• criu-dev-initcalls
• criu-dev-lsm-kerndat
• criu-dev-memprotects
• criu-dev-merge
• criu-dev-nogetpid
• criu-dev-page-xfer-sanitize
• criu-dev-rebase
• criu-dev-remote
• criu-dev-rst-mem
• criu-dev-scms
• criu-dev-sit-device
• criu-dev-stages-opt
• criu-dev-test
• criu-dev-ttys
• criu-dev-veth-test
• criu-zdtm-rpc
• master
• master-lsm-kerndat
• master-memopt
• master-merge
• master-test
• v2.11
• v2.11.1
• v2.12
• v2.12.1
• v2.4
• v2.6
• v2.7
• v3.0
• v3.1
• v3.2
• v3.2.1
• v3.3
• v3.4
• v3.5

Build # 959

Build Type

push

travis-ci

Committed by xemul

Commit Message

mem: Delayed vma/pr restore (v2)

Performance experiments show, that we spend (relatively) a lot of time
mremap-ing areas from premap area into their proper places. This time
depends on the task being restored, but for those with many vmas this
can be up to 20%.

The thing is that premapping is only needed to restore cow pages since
we don't have any API in the kernel to share a page between two or more
anonymous vmas. For non-cowing areas we map mmap() them directly in
place. But for such cases we'll also need to restore the page's contents
also from the pie code.

Doing the whole page-read code from PIE is way too complex (for now), so
the proposal is to optimize the case when we have a single local pagemap
layer. This is what pr.pieok boolean stands for.

v2:
* Fixed ARM compiling (vma addresses formatting)
* Unused tail of premapped area was left in task after restore
* Preadv-ing pages in restorer context worked on corrupted iovs
  due to mistakes in pointer arithmetics
* AIO mapping skipped at premap wasn't mapped in pie
* Growsdown VMAs should sometimes (when they are "guarded" by
  previous VMA and guard page's contents cannot be restored in
  place) be premmaped
* Always premmap for lazy-pages restore

Signed-off-by: Pavel Emelyanov <xemul@virtuozzo.com>

Run Details

19260 of 30224 relevant lines covered (63.72%)

86603.96 hits per line