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

Pavel Emelyanov xemul at parallels.com
Mon Feb 17 11:30:28 PST 2014


On 02/17/2014 11:19 PM, Cyrill Gorcunov wrote:
> On Mon, Feb 17, 2014 at 11:14:10PM +0400, Pavel Emelyanov wrote:
>>>>> +
>>>>> +		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?
> 
> Because it's easier. We don't have to track "previous" vmas and such. What we
> do -- we simply make sure the all "next" vmas are laying in same 2M area. As
> I posted you privately the results or "reading" shows that even small VMAs
> read at once by 2M chunk is still faster than doing 2 reads.
> .
> 

I see. OK, then plz, make this small improvement

> +		if (nr_vmas > 1) {
> +			pmc->start = low;
> +			pmc->end = high;

Here, if you merge at least one more vma you shift the left end of the
cache to the 2Mb boundary. There's no need in that, we can still start
reading from the current vma's start, saving a couple of bytes.

> +			pr_debug("\tcache  mode [l:%lx h:%lx]\n", pmc->start, pmc->end);
> +		} else
> +			pr_debug("\tsimple mode [l:%lx h:%lx]\n", pmc->start, pmc->end);
> +	}
> +
> +	size_map = PAGEMAP_LEN(PAGEMAP_PFN(pmc->end - pmc->start));
> +	BUG_ON(pmc->map_len < size_map);
> +
> +	if (pread(pmc->fd, pmc->map, size_map, PAGEMAP_PFN_OFF(pmc->start)) != size_map) {


Thanks,
Pavel



More information about the CRIU mailing list