2,257
edits
Changes
Jump to navigation
Jump to search
Memory dumping and restoring (edit)
Revision as of 15:17, 28 December 2011
, 15:17, 28 December 2011Created page with "== 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 i..."
== 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 ==
=== 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.
=== 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 ==
=== 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.