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 tracking
• Ptrace SEIZE that is used to grab pages from task's VM into pipe (with vmsplice)

The latter step deserves some better explanation. So in order to drain memory from task we first generate the bitmap of pages needed to be dumped (using the smaps, map_files and pagemap from proc). Then we create a set of pipe-s to put pages into. Then we infect the process with parasite code which, in turn, gets the pipes and vmsplice-s the required pages into it. Then we splice the pages from pipes into image files.

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)