mirror of
https://github.com/checkpoint-restore/criu.git
synced 2026-07-18 00:58:31 +00:00
No description
blcrcheckpointcontainercontainerscriudmtcphighly-availablelinuxmemory-trackingmigrationparasitepost-copyrestoresnapshotsuspenduserfaultfdzero-downtime
3bd08b7701
Here's why: This stage is needed to make sure all tasks have appeared and did some actions (that are called before restore_finish_stage()). With this description there's no need in involving criu process in it, this stage is purely inter-tasks sync point. Taking into account we do already make root task wait for others to complete forking (it calls restore_wait_ther_tasks()) we may rework this stage not to involve criu process in it. Here's how: So the criu task starts the forking stage, then goes waiting for "inprogress tasks". The latter wait is purely about nr_in_progress counter, thus there's no strict requirement that the stage remains the same by the time criu is woken up. Siad that, the root task waits for other tasks to finish forking, does fini_restore_mntns() (already in the code), then switches the stage to the next (the RESTORE one). Other tasks do normal staging barrier. Criu task is not woken up as nr_in_progress always remains >= 1. The result is -2 context switches -- from root task to criu and back -- which gives us good boost when restoring single task app. Signed-off-by: Pavel Emelyanov <xemul@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;