Difference between revisions of "Memory dumping and restoring"

Revision as of 19:09, 21 October 2012

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

Non linear mappings

Currently we don't support non-linear mappings (fail dump if present)

@@ Line 16: / Line 16: @@
 == Problems ==
-=== 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.
-=== 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.
+Currently we don't support non-linear mappings (fail dump if present)