mirror of
https://github.com/checkpoint-restore/criu.git
synced 2026-07-28 12:36:47 +00:00
No description
blcrcheckpointcontainercontainerscriudmtcphighly-availablelinuxmemory-trackingmigrationparasitepost-copyrestoresnapshotsuspenduserfaultfdzero-downtime
e98d16e77d
Please, see incode comment about the issue. There was an attempt to fix this feature in kernel: http://www.spinics.net/lists/arm-kernel/msg258870.html I'll send a patch for kernel with a correct justification. Still it's worth to workaround this on older kernels. mremap() after shmat() makes it possible to C/R shmem between ARMv7 CPUs. Without it C/R will fail even on the same platform. That is possible that this workaround changes *restore failure* to *corruption* in shared memory after restore. Still, I think it's worth to be applied by the following reasons: 1. All ARMv7 CPUs do not have VIPT aliasing data cache. And ARMv6 CPUs may have any, but they are not popular because of UMP. 2. SysV IPC shmem should be writable and SHMLBA unaligned (if it's only readable, then it's OK). 3. For the data corruption we need to migrate from non-VIPT cached CPUs to VIPT aliasing. 4. As this is shmem migration between platforms - quite likely we have it`s copy (in case of whole IPC namespace dump - in images). 5. C/R before on the same CPU may fail (quite likely, more than 50% of zdtm/transition/ipc failed while I've test it). So, I think it's very unlikely that someone uses CRIU to migrate from ARMv7 to ARMv6 unaligned writable shmem, but if he is - here is a BIG WARNING on restore. And after all: we've restored application as it was on checkpoint, we can't reliably tell that shmem needs align on the target platform, but we warned on restoring. I wanted to test the cpuid for VIPT caching firstly, but it's in cp15 coprocessor, which means it's unavailable from userspace. Only one reliable way to tell is to check couple of first boot lines in dmesg: [ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache Signed-off-by: Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by: Andrei Vagin <avagin@virtuozzo.com> |
||
|---|---|---|
| compel | ||
| contrib | ||
| coredump | ||
| crit | ||
| criu | ||
| Documentation | ||
| images | ||
| include/common | ||
| lib | ||
| scripts | ||
| soccr | ||
| test | ||
| .gitignore | ||
| .mailmap | ||
| .travis.yml | ||
| COPYING | ||
| CREDITS | ||
| INSTALL.md | ||
| Makefile | ||
| Makefile.compel | ||
| Makefile.config | ||
| Makefile.install | ||
| Makefile.versions | ||
| README.md | ||
CRIU (Checkpoint and Restore in Userspace)
An utility to checkpoint/restore tasks. Using this tool, you can freeze a running application (or part of it) and checkpoint it to a hard drive as a collection of files. You can then use the files to restore and run the application from the point it was frozen at. The distinctive feature of the CRIU project is that it is mainly implemented in user space.
The project home is at http://criu.org.
Pages worth starting with are:
- Kernel configuration, compilation, etc
- A simple example of usage
- More sophisticated example with graphical app
A video tour on basic CRIU features
How to contribute
- How to submit patches;
- Send all bug reports to mailing list;
- Spread the word about CRIU in social networks;