Memory dumping and restoring
How it works now
Dumping
Currently memory dumping depends on 3 big technologies:
- /proc/pid/map_files/ directory with links is used to determine
- which file is mapped
- shared memory "identifier" to detect the sharing
- mincore() system call says which pages are to be dumped and which are not (to be fixed as well)
- Ptrace SEIZE is used to dump the memory contents
Restoring
This one depends only on the /proc/pid/map_files/ to restore the shmem regions -- tasks just open some other's link and map it to create shmem region. The pages restoration just writes page data "in place".
Problems
When dumping a vma for a task its consents is dumped regardless of whether a mapping is shared. Thus for e.g. 2 tasks with shared region we'll have 2 images with the same contents.
Another problem is that a shared memory region may have different mincore() reports from different tasks. Thus neither of them is suitable for dumping the shmem with current technique.
Mincore report is bad
The existing mincore bit is not enough for several reasons.
- Swapped out memory is not reported and this is a BUG. Plan is to propose the MINCORE_SWAP bit.
- File pages are reported as present if they are in page cache regardless of whether they are mapped or not.
- When a page from private file mapping is not cow-ed (i.e. was read only) it's not necessary to dump it.
Non linear mappings
Currently there's no way to detect this mapping and dump one carefully.