Memory dumping and restoring

How it works now

Dumping

Currently memory dumping depends on 3 big technologies:

• /proc/pid/smaps file and /proc/pid/map_files/ directory with links are used to determine
  • memory areas in use by task
  • file is mapped (if any)
  • shared memory "identifier" to resolve the MAP_SHARED areas
• /proc/pid/pagemap file that reveals important flags
  • present indicates that the physical page is there. Non-present pages are not dumped.
  • anonymoys for the MAP_FILE | MAP_PRIVATE mapping indicate that the page in question is already COW-ed from the file's. Not-anonymous pages are not dumped as they are still in sync with the file
  • soft-dirty bit is used by memory changes tracker
• Ptrace SEIZE that is used to grab pages from task's VM into pipe (with vmsplice)

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".

Non linear mappings

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