• Home
  • Features
  • Pricing
  • Docs
  • Announcements
  • Sign In

xemul / criu
64%
master: 66%

Build:
Build:
LAST BUILD BRANCH: criu-dev
DEFAULT BRANCH: master
Repo Added 20 Feb 2016 10:01AM UTC
Files 217
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst

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

10 May 2017 - 21:45 coverage: 63.724%. First build
959

push

travis-ci

xemul
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>

19260 of 30224 relevant lines covered (63.72%)

86603.96 hits per line

Relevant lines Covered
Build:
Build:
30224 RELEVANT LINES 19260 COVERED LINES
86603.96 HITS PER LINE
Source Files on criu-dev-rst-mem-2
  • List 215
  • Changed 0
  • Source Changed 0
  • Coverage Changed 0
Coverage ∆ File Lines Relevant Covered Missed Hits/Line

Recent builds

Builds Branch Commit Type Ran Committer Via Coverage
959 criu-dev-rst-mem-2 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 ca... push 12 May 2017 11:21AM UTC xemul travis-ci
63.72
See All Builds (633)
  • Repo on GitHub
Troubleshooting · Open an Issue · Sales · Support · ENTERPRISE · CAREERS · STATUS
ANNOUNCEMENTS · TWITTER · TOS & SLA · Supported CI Services · What's a CI service? · Automated Testing

© 2023 Coveralls, Inc