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 == |