[CRIU] [PATCH 1/2] pagemap-cache: Introduce engine
Pavel Emelyanov
xemul at parallels.com
Mon Feb 17 10:07:23 PST 2014
On 02/17/2014 12:38 PM, Cyrill Gorcunov wrote:
>
> Pavel reported that in case if there a big number
> of small vmas present in the dumpee we're reading
> /proc/pid/pagemap too frequently.
>
> To speedup this procedue we inroduce pagemap cache.
>
> The interface is:
> - pmc_init/pmc_fini for cache initialization and freeing
> - pmc_get_map to retrieve specific PMEs array for VMA area
>
> Reported-by: Pavel Emelyanov <xemul at parallels.com>
> Signed-off-by: Cyrill Gorcunov <gorcunov at openvz.org>
> ---
> Makefile.crtools | 1 +
> include/pagemap-cache.h | 38 +++++++++++++
> pagemap-cache.c | 138 ++++++++++++++++++++++++++++++++++++++++++++++++
> 3 files changed, 177 insertions(+)
> create mode 100644 include/pagemap-cache.h
> create mode 100644 pagemap-cache.c
>
> + if (len < PMC_SIZE && (vma->e->start - low) < PMC_SIZE_GAP) {
What does the 2nd check mean?
> + size_t size_cov = len;
> + size_t nr_vmas = 1;
> +
> + pr_debug("\t%16lx-%-16lx nr:%-5zu cov:%zu\n",
> + vma->e->start, vma->e->end, nr_vmas, size_cov);
> +
> + list_for_each_entry_continue(vma, pmc->vma_head, list) {
> + if (vma->e->start > high || vma->e->end > high)
> + break;
> +
So, we just merge the next vma regardless of how far from the previous it is.
Why?
> + BUG_ON(vma->e->start < low);
> + size_cov += vma_area_len(vma);
> + nr_vmas++;
> +
> + pr_debug("\t%16lx-%-16lx nr:%-5zu cov:%zu\n",
> + vma->e->start, vma->e->end, nr_vmas, size_cov);
> + }
More information about the CRIU
mailing list