Changes

: When you take a series of dumps from a process tree, it is a very good optimization not to dump ''all'' the memory every time, but get only those memory pages that has changed since previous dump

: When you take a series of dumps from a process tree, it is a very good optimization not to dump ''all'' the memory every time, but get only those memory pages that has changed since previous dump

; Smaller freeze time for big Applications

; Smaller freeze time for big applications

: When a task uses a LOT of memory, dumping it may take time and during all this time this task should be frozen. To reduce the freeze time we can

: When a task uses a LOT of memory, dumping it may take time and during all this time this task should be frozen. To reduce the freeze time we can

* get memory from task and start writing it in images

:* get memory from task and start writing it in images

* freeze task and get only changed memory from it

:* freeze task and get only changed memory from it

; [[Live migration]]

; [[Live migration]]

: When doing live migration a lot of time takes the procedure of copying tasks' memory on remote host. And yet again, during this time process is frozen. Acting like in the previous example also reduces the freeze time, i.e. -- the live migration becomes really Live.

: When doing live migration, a lot of time is used by the procedure of copying tasks' memory to the destination host. Note that the processes are frozen during that time. Acting like in the previous example also reduces the freeze time, i.e. the live migration becomes more live.

== How we track memory changes ==

== How we track memory changes ==

In order to find out what pages in memory has changed, we [http://lwn.net/Articles/546966/ patched] the kernel. Tracking the memory changes consists of two steps:

In order to find out which memory pages have changed, we [http://lwn.net/Articles/546966/ patched] the kernel. Tracking the memory changes consists of two steps:

* Tell the kernel that we want it to keep track of memory changes by particular task by writing 4 into <code>/proc/$pid/clear_refs</code> file.

* Tell the kernel that we want it to keep track of memory changes by particular task by writing 4 into <code>/proc/$pid/clear_refs</code> file.

First of all, the

First of all, the

  #criu check

  # criu check

command (without the <code>--ms</code> option) should sat, that everything is OK. The thing is that the soft-dirty tracker is not yet merged upstream, thus you should make sure, that you're using the properly patched kernel.

command (without the <code>--ms</code> option) should sat, that everything is OK. The thing is that the soft-dirty tracker is not yet merged upstream, thus you should make sure, that you're using the properly patched kernel.

:This action dumps only part of information about processes and does this keeping tasks frozen for minimally possible time. The images generated by pre-dump cannot and should not be used for restore. After this action the proper <code>dump</code> should be performed with properly configured <code>--prev-images-dir</code> path.

:This action dumps only part of information about processes and does this keeping tasks frozen for minimally possible time. The images generated by pre-dump cannot and should not be used for restore. After this action the proper <code>dump</code> should be performed with properly configured <code>--prev-images-dir</code> path.

See also the "[[Memory dumping and restoring]]" article, section "Advanced C/R"

== See also ==

* [[Memory dumping and restoring#Advanced C/R]]

[[Category:Under the hood]]

 

[[Category: Under the hood]]

[[Category: Memory]]

[[Category: Memory]]