Jump to: navigation, search

Shared memory

141 bytes added, 22:11, 8 September 2016
some rewording
This articles describes some intricacies of handling shared Every process has one or more memory mappings,i.e. regions of virtual memory it allows to use.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 that are shared between a few processes.
== 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.
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 <code>fstatat()</code>. Now, if some processes have amapping with the same ''device:inode'' pair, this mapping is marked as shared between them these processesand is dumped as such.
Dumping Note that <code>fstatat()</code> works because the kernel actually creates a mapping means writing an entry into proceess' mm.img hiddentmpfs file and storing , not visible from any tmpfs mounts, but accessible via its contents. For shared mapping the contents is stored into pagemap-shmem.img and pages.img pair of images (see [[Memory dumps]])<code>/proc/$PID/map_files/</code> entry.
ItDumping a mapping means two things:* writing an entry into process's important to note that mm.img file;* storing the above mechanism works not just for the file-based actual mapping data (contents).For shared mappings,but also for the anonymous onescontents is stored into a pair of image files: pagemap-shmem. img and pages.img.For an anonymous mappingdetails, kernel actually creates see [[Memory dumps]]. Note that different processes can map different parts of a hiddenshared memory segment.tmpfs fileIn this case, CRIU first collects mapping offsets and so <code>fstatat()</code> on lengths from all the <code>/proc/$PID/map_files/</code> entryprocessesworks to determine the the total segment size, then reads all the same way as for other files. The tmpfs file itself is not visible parts contentsfrom any tmpfsmounts, but can be opened via its <code>map_files</code> entrythe respective processes.
== Restore ==

Navigation menu