Memory dumping and restoring

From CRIU

Contents 1 How it works now 1.1 Dumping 1.2 Restoring 2 Problems 2.1 Shared memory dump 2.2 Mincore report is bad 2.3 Non linear mappings

[edit] How it works now

[edit] 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

[edit] 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".

[edit] Problems

[edit] Shared memory dump

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.

[edit] Mincore report is bad

The existing mincore bit is not enough for several reasons.

1. Swapped out memory is not reported and this is a BUG. Plan is to propose the MINCORE_SWAP bit.
2. File pages are reported as present if they are in page cache regardless of whether they are mapped or not.
3. When a page from private file mapping is not cow-ed (i.e. was read only) it's not necessary to dump it.

[edit] Non linear mappings

Currently there's no way to detect this mapping and dump one carefully.