Difference between revisions of "Comparison to other CR projects"

From CRIU
Jump to navigation Jump to search
(Table style fix)
(Add OpenVZ intro table)
Line 28: Line 28:
 
! DMTCP
 
! DMTCP
 
! BLCR
 
! BLCR
 +
! OpenVZ
  
 
|-
 
|-
Line 34: Line 35:
 
| x86, x86_64, ARM
 
| x86, x86_64, ARM
 
| x86, x86_64, PPC/PPC64, ARM
 
| x86, x86_64, PPC/PPC64, ARM
 +
| x86, x86_64
  
 
|-
 
|-
 
| OS
 
| OS
 +
| Linux
 
| Linux
 
| Linux
 
| Linux
 
| Linux
Line 46: Line 49:
 
| No
 
| No
 
| No, just need to load module. May be problems with installation on new kernels
 
| No, just need to load module. May be problems with installation on new kernels
 +
| Yes
  
 
|-
 
|-
Line 52: Line 56:
 
| Yes
 
| Yes
 
| Yes
 
| Yes
 +
| No
  
 
|-
 
|-
Line 58: Line 63:
 
| No
 
| No
 
| No
 
| No
 +
| Yes
  
 
|-
 
|-
Line 64: Line 70:
 
| No
 
| No
 
| Yes. There are some difficulties with statically linked applications, and with LinuxThreads (it does not support them at all)
 
| Yes. There are some difficulties with statically linked applications, and with LinuxThreads (it does not support them at all)
 +
| No
  
  
Line 71: Line 78:
 
| Yes. It preloadsthe DMTCP library. That library runs before the routinemain(). It creates a second thread. Thecheckpoint thread then creates a socket to the DMTCP coordinator andregisters itself. The checkpoint thread also creates a signal handler.
 
| Yes. It preloadsthe DMTCP library. That library runs before the routinemain(). It creates a second thread. Thecheckpoint thread then creates a socket to the DMTCP coordinator andregisters itself. The checkpoint thread also creates a signal handler.
 
| Yes. CR shall notify processes when a checkpoint is to occur (before the kernel takes a checkpoint) to allow the processes to prepare itself accordingly.
 
| Yes. CR shall notify processes when a checkpoint is to occur (before the kernel takes a checkpoint) to allow the processes to prepare itself accordingly.
 +
| No
  
  
Line 78: Line 86:
 
| Yes, because of wrappers on system calls
 
| Yes, because of wrappers on system calls
 
| Yes, because of wrappers on system calls
 
| Yes, because of wrappers on system calls
 +
| No
  
 
|-
 
|-
Line 84: Line 93:
 
| Yes, if both kernels are recent
 
| Yes, if both kernels are recent
 
| Yes, but if all components are the same. Even if prelinked addresses are different,it will not restore, but it can save the whole used libs and localization files to restore program on the different machine
 
| Yes, but if all components are the same. Even if prelinked addresses are different,it will not restore, but it can save the whole used libs and localization files to restore program on the different machine
 +
| Yes
  
 
|-
 
|-
Line 90: Line 100:
 
| No. It doesn't support namespaces, so it probably can’t dump containers  
 
| No. It doesn't support namespaces, so it probably can’t dump containers  
 
| Looks like no
 
| Looks like no
 +
| Yes
  
 
|-
 
|-
Line 96: Line 107:
 
| Yes. OpenMPI, MPICH2, OpenMP, Cilk are alredy supported and Infiniband is in progress
 
| Yes. OpenMPI, MPICH2, OpenMP, Cilk are alredy supported and Infiniband is in progress
 
| Yes. Cray MPI, Intel MPI, LAM/MPI, MPICH-V, MPICH2, MVAPICH, Open MPI, SGI MPT
 
| Yes. Cray MPI, Intel MPI, LAM/MPI, MPICH-V, MPICH2, MVAPICH, Open MPI, SGI MPT
 +
| Yes
  
 
|-
 
|-
Line 102: Line 114:
 
| Yes
 
| Yes
 
| No
 
| No
 +
| Yes
  
 
|-
 
|-
Line 108: Line 121:
 
| Yes, by using vnc
 
| Yes, by using vnc
 
| Looks like no
 
| Looks like no
 +
| Yes, by using vnc
  
  
Line 115: Line 129:
 
| Yes. Plugins and API
 
| Yes. Plugins and API
 
| Not yet
 
| Not yet
 +
| Yes. via ioctl calls
  
 
|-
 
|-
Line 124: Line 139:
 
| Yes
 
| Yes
 
| No
 
| No
 +
| Yes
  
 
|-
 
|-
Line 130: Line 146:
 
| Not yet. Developers of dmtcp had no request for this
 
| Not yet. Developers of dmtcp had no request for this
 
| Not yet
 
| Not yet
 +
| Yes
  
 
|-
 
|-
Line 136: Line 153:
 
| Yes
 
| Yes
 
| Not yet
 
| Not yet
 +
| Yes
  
 
|-
 
|-
Line 142: Line 160:
 
| No, but you can write a simple DMTCP plugin that tells DMTCP how you want to reconnect on restart
 
| No, but you can write a simple DMTCP plugin that tells DMTCP how you want to reconnect on restart
 
| No
 
| No
 +
| Yes
  
 
|-
 
|-
Line 147: Line 166:
 
| No
 
| No
 
| Not yet, developing is on the half-way
 
| Not yet, developing is on the half-way
 +
| No
 
| No
 
| No
  
 
|-
 
|-
 
| Multithread support
 
| Multithread support
 +
| Yes
 
| Yes
 
| Yes
 
| Yes
 
| Yes
Line 157: Line 178:
 
|-
 
|-
 
| Multiprocess
 
| Multiprocess
 +
| Yes
 
| Yes
 
| Yes
 
| Yes
 
| Yes
Line 166: Line 188:
 
| Yes
 
| Yes
 
| Not yet
 
| Not yet
 +
| Yes
  
 
|-
 
|-
Line 172: Line 195:
 
| No
 
| No
 
| No
 
| No
 +
| Yes
  
 
|-
 
|-
Line 178: Line 202:
 
| No
 
| No
 
| No
 
| No
 +
| Yes
  
 
|-
 
|-
Line 184: Line 209:
 
| Yes
 
| Yes
 
| No
 
| No
 +
| Yes
  
 
|-
 
|-
Line 190: Line 216:
 
| Yes
 
| Yes
 
| No
 
| No
 +
| Yes
  
 
|-
 
|-
Line 196: Line 223:
 
| Yes
 
| Yes
 
| Yes, partially  
 
| Yes, partially  
 +
| Yes
  
 
|-
 
|-
Line 202: Line 230:
 
| Yes
 
| Yes
 
| Not yet
 
| Not yet
 +
| Yes
  
 
|-
 
|-
 
| Terminals
 
| Terminals
 
| Yes, but only Unix98 PTYs
 
| Yes, but only Unix98 PTYs
 +
| Yes
 
| Yes
 
| Yes
 
| Yes
 
| Yes
Line 214: Line 244:
 
| Yes, epoll, eventfd, signalfd are already supported and inotify will be supported in future
 
| Yes, epoll, eventfd, signalfd are already supported and inotify will be supported in future
 
| Looks like no
 
| Looks like no
 +
| Yes
  
 
|-
 
|-
Line 219: Line 250:
 
| Yes
 
| Yes
 
| No. Any counter or timer active since the beginning of a process will consider the restarted process to be a new process.
 
| No. Any counter or timer active since the beginning of a process will consider the restarted process to be a new process.
 +
| Yes
 
| Yes
 
| Yes
  
Line 226: Line 258:
 
| Yes. System V shared memory(shmget, etc.), mmap-based shared memory, shared sockets, pipes, file descriptors
 
| Yes. System V shared memory(shmget, etc.), mmap-based shared memory, shared sockets, pipes, file descriptors
 
| No, but it is planned to suppord shared mmap regions
 
| No, but it is planned to suppord shared mmap regions
 +
| Yes
  
 
|-
 
|-
Line 231: Line 264:
 
| No
 
| No
 
| Looks like yes
 
| Looks like yes
 +
| No
 
| No
 
| No
  
Line 239: Line 273:
 
| Yes, looks like null and zero are supported
 
| Yes, looks like null and zero are supported
 
| Yes, /dev/null and /dev/zero
 
| Yes, /dev/null and /dev/zero
 +
| Yes
  
 
|-
 
|-
Line 245: Line 280:
 
| Looks like no
 
| Looks like no
 
| Not yet
 
| Not yet
 +
| Yes
  
 
|}
 
|}

Revision as of 05:36, 16 July 2013

This pages tries to explain differences between CRIU and other C/R solutions.

DMTCP

DMTCP implements checkpoint/restore of a process on a library level. This means, that if you want to C/R some application you should launch one with DMTCP library (dynamically) linked from the very beginning. When launched like this, the DMTCP library intercepts a certain amount of library calls from the application, builds a shadow data-base of information about process' internals and then forwards the request down to glibc/kernel. The information gathered is to be used to create an image of the application. With this approach, one can only dump applications known to run successfully with the DMTCP libraries, but the latter doesn't provide proxies for all kernel APIs (for example, inotify() is known to be unsupported). Another implication of this approach is potential performance issues that arise due to proxying of requests.

Restoration of process set is also tricky, as it frequently requires restoring an object with the predefined ID and kernel is known to provide no APIs for several of them. For example, kernel cannot fork a process with the desired PID. To address that, DMTCP fools a process by intercepting the getpid() library call and providing fake PID value to the application. Such behavior is very dangerous, as application might see wrong files in the /proc filesystem if it will try to access one via its PID.

CRIU, on the other hand, doesn't require any libraries to be pre-loaded. It will checkpoint and restore any arbitrary application, as long as kernel provides all needed facilities. Kernel support for some of CRIU features were added recently, essentially meaning that a recent kernel version might be required.

BLCR

Berkeley Lab Checkpoint/Restart (BLCR) is a part of the Scalable Systems Software Suite , developed by the Future Technologies Group at Lawrence Berkeley National Lab under SciDAC funding from the United States Department of Energy. It is an Open Source, system-level checkpointer designed with High Performance Computing (HPC) applications in mind: in particular CPU and memory intensive batch-scheduled MPI jobs. BLCR is implemented as a GPL-licensed loadable kernel module for Linux 2.4.x and 2.6.x kernels on the x86, x86_64, PPC/PPC64, ARM architectures, and a small LGPL-licensed library.

CRIU, DMTCP, BLCR

“looks\seems like yes/no” - i found only unproved message(s) saying “yes”/“no”

“not yet” - it is officially planned or i found no reasons, why it can’t be done.


CRIU DMTCP BLCR OpenVZ
Arch x86_64, ARM x86, x86_64, ARM x86, x86_64, PPC/PPC64, ARM x86, x86_64
OS Linux Linux Linux Linux
Need in modified kernel Yes, but only for some extra features. All unnecessary features are already in new kernel versions No No, just need to load module. May be problems with installation on new kernels Yes
App need to pre-load special libraries No Yes Yes No
Requires root privileges Yes, due to restrictions from some kernel APIs it uses No No Yes
Need to modify programs to C/R No No Yes. There are some difficulties with statically linked applications, and with LinuxThreads (it does not support them at all) No


Need to prepare tasks No Yes. It preloadsthe DMTCP library. That library runs before the routinemain(). It creates a second thread. Thecheckpoint thread then creates a socket to the DMTCP coordinator andregisters itself. The checkpoint thread also creates a signal handler. Yes. CR shall notify processes when a checkpoint is to occur (before the kernel takes a checkpoint) to allow the processes to prepare itself accordingly. No


Does it change behavior of the c/r-ed programs? No Yes, because of wrappers on system calls Yes, because of wrappers on system calls No
Live migration Yes, even if kernel, libs, etc are newer. Can use Memory Changes Tracking to decrease freeze time Yes, if both kernels are recent Yes, but if all components are the same. Even if prelinked addresses are different,it will not restore, but it can save the whole used libs and localization files to restore program on the different machine Yes
Containers Yes, LXC and OpenVZ containers No. It doesn't support namespaces, so it probably can’t dump containers Looks like no Yes
Parallel/distributed computations libraries No (in plans) Yes. OpenMPI, MPICH2, OpenMP, Cilk are alredy supported and Infiniband is in progress Yes. Cray MPI, Intel MPI, LAM/MPI, MPICH-V, MPICH2, MVAPICH, Open MPI, SGI MPT Yes
C/R gdb with debugging app No, because they are using the same interface Yes No Yes
X-Windows apps (KDE, GNOME, etc) Yes, by using vnc Yes, by using vnc Looks like no Yes, by using vnc


Solutions for invocation in the custom software No, only fork + daemonize + exec Yes. Plugins and API Not yet Yes. via ioctl calls
Unix sockets Yes Yes No Yes
UDP sockets Yes, both ipv4 and ipv6 Not yet. Developers of dmtcp had no request for this Not yet Yes
TCP sockets Yes Yes Not yet Yes
Established tcp connection Yes No, but you can write a simple DMTCP plugin that tells DMTCP how you want to reconnect on restart No Yes
Infiniband No Not yet, developing is on the half-way No No
Multithread support Yes Yes Yes Yes
Multiprocess Yes Yes Yes Yes
Process groups and sessions Yes Yes Not yet Yes
Zombies Yes No No Yes
Namespaces Yes No No Yes
Ptraced programs No Yes No Yes
System V IPC Yes Yes No Yes
Memory mappings Yes, all kinds Yes Yes, partially Yes
Pipes Yes Yes Not yet Yes
Terminals Yes, but only Unix98 PTYs Yes Yes Yes
Non-posix files (inotify, signalfd, eventfd, etc) Yes, inotify, fanotify, epoll, signalfd, eventfd Yes, epoll, eventfd, signalfd are already supported and inotify will be supported in future Looks like no Yes
Timers Yes No. Any counter or timer active since the beginning of a process will consider the restarted process to be a new process. Yes Yes
Shared resources (files, mm, etc.) Yes. SysVIPC, files, fd table and memory Yes. System V shared memory(shmget, etc.), mmap-based shared memory, shared sockets, pipes, file descriptors No, but it is planned to suppord shared mmap regions Yes
Block devices No Looks like yes No No


Character devices Yes, only /dev/null, /dev/zero, etc. are supported Yes, looks like null and zero are supported Yes, /dev/null and /dev/zero Yes
Capture the contents of open files Yes, if file is unlinked Looks like no Not yet Yes

Sources

DMTCP:

BLCR:

External links

Retrieved from "https://criu.org/index.php?title=Comparison_to_other_CR_projects&oldid=1125"