5
edits
Changes
Jump to navigation
Jump to search
mLine 1:
Line 1: − This articles describes some intricacies of handling shared memory mappings, i.e. mappings that are shared between a few processes.+ + + + − Every process has one or more mmaped files. Some mappings (for example, ones of shared libraries)+ − are shared between a few processes. During the checkpointing, CRIU need to figure out − − + − + − is collected and sorted. Now, if any few processes have a mapping with same ''device'' and ''inode'',+ − + − It's important to note that the above mechanism works not just for the file-based mappings,+ − but also for the anonymous ones. For an anonymous mapping, kernel actually creates a hidden+ − + − works the same way as for other files. The tmpfs file itself is not visible from any tmpfs+ − mounts, but can be opened via its <code>map_files</code> entry.+ + + + + + + + + + − + − To restore file mappings, no tricks are needed, they are opened and mmaped with with a MAP_SHARED flag set.+ − − Anonymous memory mappings, though, need some work to be restored as such. Here is how it is done. Line 82:
Line 90: +
→Checkpoint: twice 'the'
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.
== Checkpoint ==
== Checkpoint ==
During the checkpointing, CRIU needs to figure out all the shared mappings in order to dump them as such.
all the mappings that are shared in order to dump them as such.
It does so by performing <code>fstatat()</code> for each entry in <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'' and ''inode'' fields of the structure returned by fstatat(). This information
noting the ''device:inode'' pair of the structure returned by <code>fstatat()</code>. Now, if some processes
have a mapping with the same ''device:inode'' pair, this mapping is marked as shared between these processes
this mapping is a shared one and should be dumped as such.
and dumped as such.
Note that <code>fstatat()</code> works because the kernel actually creates a hidden
tmpfs file, not visible from any tmpfs mounts, but accessible via its
tmpfs file, and so <code>fstatat()</code> on the <code>/proc/$PID/map_files/</code> entry
<code>/proc/$PID/map_files/</code> entry.
Dumping a mapping means two things:
* writing an entry into process' mm.img file;
* storing the actual mapping data (contents).
For shared mappings, the contents is stored into a pair of image files: pagemap-shmem.img and pages.img.
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 total segment size, then reads all the parts contents
from the respective processes.
== Restore ==
== Restore ==
During the restore, CRIU already knows which mappings are shared, so they need to be restored as shared.
During the restore, CRIU already knows which mappings are shared, so they need to be
restored as such. Here is how it is done.
Among all the processes sharing a mapping, the one with the lowest PID among the group
Among all the processes sharing a mapping, the one with the lowest PID among the group
[[Category:Memory]]
[[Category:Memory]]
[[Category:Under the hood]]
[[Category:Under the hood]]
[[Category:Editor help needed]]