[CRIU] [PATCH v5 5/8] criu: pagemap: add entries for zero pages

[Mike Rapoport]

On Wed, Jul 6, 2016 at 11:10 AM, Pavel Emelyanov <xemul at virtuozzo.com> wrote:
>
>> @@ -165,9 +168,12 @@ static int generate_iovs(struct vma_area *vma, struct page_pipe *pp, u64 *map, u
>>               if (has_parent && page_in_parent(at[pfn])) {
>>                       ret = page_pipe_add_hole(pp, vaddr);
>>                       pages[0]++;
>> +             } else if (page_is_zero(at[pfn])) {
>> +                     ret = page_pipe_add_zero(pp, vaddr);
>> +                     pages[1]++;
>
> This means, that zero holes that are in parent will be written as ... has_parent :\
> Hm... Is this correct? Presumably yes, but ...

Well, we can change the order of if'else here, and put the zero hole
in the image no matter if they are in parent or not.
I don't know what is "correct" here. Maybe having zero pages in each
image is slightly faster.

>>               } else {
>>                       ret = page_pipe_add_page(pp, vaddr, ppb_flags);
>> -                     pages[1]++;
>> +                     pages[2]++;
>>               }
>>
>>               if (ret) {
>
>> @@ -342,6 +355,15 @@ static int dump_hole(struct page_xfer *xfer, struct page_pipe_iovs *iov,
>>       return 0;
>>  }
>>
>> +static int dump_holes(struct page_xfer *xfer, struct page_pipe *pp,
>> +                   void *limit, unsigned long off)
>> +{
>> +     if (dump_hole(xfer, &pp->holes, limit, off, PS_IOV_HOLE))
>> +             return -1;
>> +
>> +     return dump_hole(xfer, &pp->zeros, limit, off, PS_IOV_ZERO);
>
> This generates unsorted pagemap.img. Restore part currently assumes that it's sorted.

Why do you think so? Obviously, it was no the intention :)
The dump_hole anyway only dumps holes that are below limit, which is
in turn the beginning of the next IOV with pages...

>> +}
>> +
>>  int page_xfer_dump_pages(struct page_xfer *xfer, struct page_pipe *pp,
>>               unsigned long off)
>>  {
>



-- 
Sincerely yours,
Mike.