Difference between revisions of "Shared memory"
(created (not finished)) |
|||
| Line 1: | Line 1: | ||
| + | This articles describes some intricacies of handling shared memory mappings, i.e. mappings that are shared between a few processes. | ||
| + | |||
| + | == Checkpoint == | ||
| + | |||
| + | 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 | ||
| + | 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>, | ||
| + | noting the ''device'' and ''inode'' fields of the structure returned by fstatat(). This information | ||
| + | is collected and sorted. Now, if any few processes have a mapping with same ''device'' and ''inode'', | ||
| + | this mapping is a shared one and should be dumped as such. | ||
| + | |||
| + | == Restore == | ||
| + | |||
| + | Upon restore, CRIU already knows which mappings are shared, and the trick is to restore them as such. | ||
| + | For that, two different approaches are used, depending on the availability. | ||
| + | |||
| + | The common part is, between the processes sharing a mapping, the one with the lowest PID | ||
| + | among the group performs the actual <code>mmap()</code>, while all the others wait | ||
| + | for the mapping to appear and, once it's available, use it. | ||
| + | |||
| + | === memfd === | ||
| + | |||
| + | Linux kernel v3.17 adds a [http://man7.org/linux/man-pages/man2/memfd_create.2.html memfd_create()] | ||
| + | syscall. CRIU restore checks if it is available from the running kernel; it yes, it is used. | ||
| + | |||
| + | FIXME how | ||
| + | |||
| + | === /proc/$PID/map_files/ === | ||
| + | |||
| + | This method is used if memfd is not available. The limitation is, /proc/$PID/map_files/ is not available | ||
| + | for users inside user namespaces (due to security concerns), so it's not possible to use it if there | ||
| + | are any user namespaces in the dump. | ||
| + | |||
| + | FIXME how | ||
| + | |||
| + | === | ||
| + | |||
[[Category:Memory]] | [[Category:Memory]] | ||
[[Category:Under the hood]] | [[Category:Under the hood]] | ||
[[Category:Empty articles]] | [[Category:Empty articles]] | ||
Revision as of 00:27, 1 September 2016
This articles describes some intricacies of handling shared memory mappings, i.e. mappings that are shared between a few processes.
Checkpoint
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 all the mappings that are shared in order to dump them as such.
It does so by performing fstatat() for each entry in /proc/$PID/map_files/,
noting the device and inode fields of the structure returned by fstatat(). This information
is collected and sorted. Now, if any few processes have a mapping with same device and inode,
this mapping is a shared one and should be dumped as such.
Restore
Upon restore, CRIU already knows which mappings are shared, and the trick is to restore them as such. For that, two different approaches are used, depending on the availability.
The common part is, between the processes sharing a mapping, the one with the lowest PID
among the group performs the actual mmap(), while all the others wait
for the mapping to appear and, once it's available, use it.
memfd
Linux kernel v3.17 adds a memfd_create() syscall. CRIU restore checks if it is available from the running kernel; it yes, it is used.
FIXME how
/proc/$PID/map_files/
This method is used if memfd is not available. The limitation is, /proc/$PID/map_files/ is not available for users inside user namespaces (due to security concerns), so it's not possible to use it if there are any user namespaces in the dump.
FIXME how