Difference between revisions of "Memory dumping and restoring"

From CRIU
Jump to navigation Jump to search
(Categorize)
Line 9: Line 9:
 
** 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)
 
* 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 grab pages from task's VM into pipe (with vmsplice)
  
 
=== Restoring ===
 
=== 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".
 
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 ===
 
=== Non linear mappings ===

Revision as of 21:15, 14 May 2013

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 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)