Memory dumping and restoring

Revision as of 17:22, 28 January 2015 by Xemul (talk | contribs)

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)

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)