Difference between revisions of "Memory dumping and restoring"
Jump to navigation
Jump to search
| Line 8: | Line 8: | ||
** which file is mapped | ** which file is mapped | ||
** shared memory "identifier" to detect the sharing | ** shared memory "identifier" to detect the sharing | ||
| − | * | + | * proc pagemap file 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 | * Ptrace SEIZE is used to dump the memory contents | ||
Revision as of 19:10, 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
- proc pagemap file 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)