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

[Pavel Emelyanov]

On 02/17/2014 11:11 PM, Cyrill Gorcunov wrote:
> 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

OK

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

Why don't we check the size of the gap between the 1st and the 2nd (and all
subsequent) vmas?

> 	Cyrill
> .
>