[CRIU] [PATCH 1/2] pagemap-cache: Introduce engine

[Cyrill Gorcunov]

On Mon, Feb 17, 2014 at 10:07:23PM +0400, Pavel Emelyanov wrote:
> 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?

This stands to estimate that VMA is really close to 2M bound and it
make sence to do a forward lookup over the next VMAs in list. Imagine

   |           |         |      |
  2M        vma->start  2M    vma->end

> > +
> > +		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?

We pick next only if previous VMA is less than 2M and lays close to low 2M
bound, then next VMA is tested to have both addresses inside high 2M bound.

	Cyrill