[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