Changes

Jump to navigation Jump to search
no edit summary
Line 1: Line 1: −
== Dumping ==
+
== Basic C/R ==
 +
 
 +
=== Dumping ===
    
Currently memory dumping depends on 3 big technologies:
 
Currently memory dumping depends on 3 big technologies:
Line 15: Line 17:  
The latter step deserves some better explanation. So in order to drain memory from task we first generate the bitmap of pages needed to be dumped (using the smaps, map_files and pagemap from proc). Then we create a set of pipe-s to put pages into. Then we infect the process with [[parasite code]] which, in turn, gets the pipes and <code>vmsplice</code>-s the required pages into it. Then we <code>splice</code> the pages from pipes into image files.
 
The latter step deserves some better explanation. So in order to drain memory from task we first generate the bitmap of pages needed to be dumped (using the smaps, map_files and pagemap from proc). Then we create a set of pipe-s to put pages into. Then we infect the process with [[parasite code]] which, in turn, gets the pipes and <code>vmsplice</code>-s the required pages into it. Then we <code>splice</code> the pages from pipes into image files.
   −
== Restoring ==
+
=== Restoring ===
    
Restoring is pretty straightforward as during restore CRIU morphs itself into the target task. Two things worth mentioning.
 
Restoring is pretty straightforward as during restore CRIU morphs itself into the target task. Two things worth mentioning.
   −
=== [[COW]] ===
+
;[[COW]]
 +
:Anonymous private mappings might have pages shared between tasks till they get COW-ed. To restore this CRIU pre-restores those pages before forking the child processes and <code>mremap</code>-s them in the [[restorer context|final stage]].
   −
Anonymous private mappings might have pages shared between tasks till they get COW-ed. To restore this CRIU pre-restores those pages before forking the child processes and <code>mremap</code>-s them in the [[restorer context|final stage]].
+
;[[Shared memory]]
 +
:Those areas are implemented in the kernel by supporting a pseudo file on a hidden tmpfs mount. So on restore we just determine who will create the shared are and who will attach to it (see the [[postulates]]). Then the creator <code>mmap</code>-s the region and the others open the /proc/pid/map_files/ link. However, on the recent kernels, we use the new <code>memfd</code> system call that does similar thing but works for user namespaces. Briefly -- creator creates the memfd, all the others get one via /proc/pid/fd link which is not that strict as compared to the map_files.
   −
=== [[Shared memory]] ===
+
=== Non linear mappings ===
 
  −
Those areas are implemented in the kernel by supporting a pseudo file on a hidden tmpfs mount. So on restore we just determine who will create the shared are and who will attach to it (see the [[postulates]]). Then the creator <code>mmap</code>-s the region and the others open the /proc/pid/map_files/ link. However, on the recent kernels, we use the new <code>memfd</code> system call that does similar thing but works for user namespaces. Briefly -- creator creates the memfd, all the others get one via /proc/pid/fd link which is not that strict as compared to the map_files.
  −
 
  −
 
  −
== Non linear mappings ==
      
Currently we don't support non-linear mappings (fail dump if present)
 
Currently we don't support non-linear mappings (fail dump if present)
    
[[Category:Under the hood]]
 
[[Category:Under the hood]]
 +
 +
== Advanced C/R ==

Navigation menu