Changes

141 bytes added ,  22:11, 8 September 2016
some rewording
Line 1: Line 1: −
This articles describes some intricacies of handling shared memory mappings,
+
Every process has one or more memory mappings, i.e. regions of virtual memory it allows to use.
i.e. anonymous (not file-based) mappings that are shared between a few processes.
+
Some such mappings can be shared between a few processes, and they are called shared mappings.
 +
In other words, these are shared '''anonymous (not file-based) memory mappings'''.
 +
The article describes some intricacies of handling such mappings.  
    
== Checkpoint ==
 
== Checkpoint ==
   −
Every process has one or more so called mmapings -- regions of virtual memory which it's allowed to use. Some mappings can be shared between a few processes.
   
During the checkpointing, CRIU needs to figure out all the shared mappings in order to dump them as such.
 
During the checkpointing, CRIU needs to figure out all the shared mappings in order to dump them as such.
    
It does so by calling <code>fstatat()</code> on each entry found in the <code>/proc/$PID/map_files/</code>,
 
It does so by calling <code>fstatat()</code> on each entry found in the <code>/proc/$PID/map_files/</code>,
noting the ''device:inode'' pair of the structure returned by fstatat(). Now, if some processes have a
+
noting the ''device:inode'' pair of the structure returned by <code>fstatat()</code>. Now, if some processes
mapping with the same ''device:inode'' pair, this mapping is marked as shared between them and is dumped as such.
+
have a mapping with the same ''device:inode'' pair, this mapping is marked as shared between these processes
 +
and dumped as such.
   −
Dumping a mapping means writing an entry into proceess' mm.img file and storing its contents. For shared
+
Note that <code>fstatat()</code> works because the kernel actually creates a hidden
mapping the contents is stored into pagemap-shmem.img and pages.img pair of images (see [[Memory dumps]]).
+
tmpfs file, not visible from any tmpfs mounts, but accessible via its
 +
<code>/proc/$PID/map_files/</code> entry.
   −
It's important to note that the above mechanism works not just for the file-based mappings,
+
Dumping a mapping means two things:
but also for the anonymous ones. For an anonymous mapping, kernel actually creates a hidden
+
* writing an entry into process' mm.img file;
tmpfs file, and so <code>fstatat()</code> on the <code>/proc/$PID/map_files/</code> entry
+
* storing the actual mapping data (contents).
works the same way as for other files. The tmpfs file itself is not visible from any tmpfs
+
For shared mappings, the contents is stored into a pair of image files: pagemap-shmem.img and pages.img.
mounts, but can be opened via its <code>map_files</code> entry.
+
For details, see [[Memory dumps]].
 +
 
 +
Note that different processes can map different parts of a shared memory segment.
 +
In this case, CRIU first collects mapping offsets and lengths from all the processes
 +
to determine the the total segment size, then reads all the parts contents
 +
from the respective processes.
    
== Restore ==
 
== Restore ==