Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

“PE_LAZY” flag in parent pagemap images? #2542

Open
obsidian0215 opened this issue Dec 11, 2024 · 0 comments
Open

“PE_LAZY” flag in parent pagemap images? #2542

obsidian0215 opened this issue Dec 11, 2024 · 0 comments

Comments

@obsidian0215
Copy link

Description

I tried to implement a hybrid live-migration using CRIU, so I used criu pre-dump to migrate part of process's memory like post-copy. But when I executed criu dump --lazy-pages and criu restore --lazy-pages with criu lazy-pages as post-copy, I found that size of memory that migrated by uffd is almost equal to the memory size when I only use post-copy, which means pre-copy cannot affect(reduce) transmission of post-copy.
In order to identify the cause of this phenomenon, I dived into CRIU's source code and found that CRIU skips pagemap entrys with PE_LAZY during memory's lazy-restore. However, many of present pages in the parent pagemap images are also marked as PE_LAZY, resulting in almost no utilization of parent page images when restoring. So I have a question about the meaning of adding the PE_LAZY flag to the pages selected by pre-dump - the pages selected by dump can skip writing to the image, transferring, and restoring through PE_LAZY, but the pre dump pages have already been written to the image and transferred, and PE_LAZY seems to just skip restoring. This actually increases unnecessary memory transfer, so I believe it's better to avoid PE_LAZY for pagemaps in pre-dump. If this idea is incorrect, I would like to know the reason behind it. Thank you.

Steps to reproduce the issue:

  1. criu pre-dump ... for several iterations and transfer the pre-dumped memory
  2. criu dump --lazy-pages ... and transfer the dumped states
  3. criu restore --lazy-pages with criu lazy-pages to restore the process

Describe the results you received:
The memory size transmitted by Lazy-Pages is not affected by Pre-Dump

Describe the results you expected:
The memory size transmitted by Lazy-Pages may be reduced by Pre-Dump

Additional information you deem important (e.g. issue happens only occasionally):
in criu/mem.c:

static int generate_iovs(struct pstree_item *item, struct vma_area *vma, struct page_pipe *pp, pmc_t *pmc, u64 *pvaddr,
			 bool has_parent)
{
    ...
    if (vma_entry_can_be_lazy(vma->e) && !is_stack(item, vaddr))
          ppb_flags |= PPB_LAZY;
    ...
}

(PPB_LAZY will be transformed to PE_LAZY when generating pagemap.)

static int restore_priv_vma_content(struct pstree_item *t, struct page_read *pr)
{
        ...
	/*
	 * Read page contents.
	 */
	while (1) {
		unsigned long off, i, nr_pages;

		ret = pr->advance(pr);
		if (ret <= 0)
			break;

		va = (unsigned long)decode_pointer(pr->pe->vaddr);
		nr_pages = pr->pe->nr_pages;

		/*
		 * This means that userfaultfd is used to load the pages
		 * on demand.
		 */
		if (opts.lazy_pages && pagemap_lazy(pr->pe)) {
			pr_debug("Lazy restore skips %ld pages at %lx\n", nr_pages, va);
			pr->skip_pages(pr, nr_pages * PAGE_SIZE);
			nr_lazy += nr_pages;
			continue;
		}
          ...
}

CRIU logs and information:

CRIU full dump/restore logs:

NULL

Output of `criu --version`:

4.0

Output of `criu check --all`:

Looks good.

Additional environment details:

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant