[CRIU] [PATCH v4 07/12] criu: page-xfer: add ability to skip writing lazy pages

[Mike Rapoport]

On Thu, Jun 9, 2016 at 4:49 PM, Pavel Emelyanov <xemul at virtuozzo.com> wrote:
> On 06/09/2016 04:42 PM, Mike Rapoport wrote:
>> On Thu, Jun 9, 2016 at 4:39 PM, Pavel Emelyanov <xemul at virtuozzo.com> wrote:
>>> On 06/09/2016 04:24 PM, Mike Rapoport wrote:
>>>> On Thu, Jun 9, 2016 at 4:22 PM, Pavel Emelyanov <xemul at virtuozzo.com> wrote:
>>>>> On 06/09/2016 04:12 PM, Mike Rapoport wrote:
>>>>>> On Thu, Jun 9, 2016 at 4:12 PM, Mike Rapoport <mike.rapoport at gmail.com> wrote:
>>>>>>>>
>>>>>>>> I have a question here -- if page_xfer_dump_pages sends a pagemap the receiver
>>>>>>>> would expect the subsequent pages on the socket, but instead, it _may_ receive
>>>>>>>> next pagemap if the previous one was lazy. How it this handled?
>>>>>>>
>>>>>>> Hmmm. It is not... I think that page-server and, most probably,
>>>>>>> incremental dumps are not compatible with lazy-pages...
>>>>>>
>>>>>> As of now :(
>>>>>
>>>>> OK... And when in the lazy-pages code-flow would this page_xfer_dump_pages()
>>>>> get called?
>>>>
>>>> At the "usual place", dump_pages will have yet another boolean
>>>> parameter 'lazy' that will be passed to page_xfer_dump_pages()
>>>
>>> OK, so we do "regular" dump that doesn't write lazy pages into pages.img, right?
>>
>> Yes
>
> OK, this creates ... broken pagemap/pages image set, as pagemap is present,
> but the respective page-set is not :( Can we add optional bool lazy bit
> for this?

I'd add entire 'u32 flags' for upward compatibility :)

> AFAIU the restore side reads the pagemap and understands that
> it's lazy by looking at VMA, does it?

Yep, the restore side reads pagemap, checks if the vma can be lazy and
skips the pages. The page read has a hack to avoid lseek of pages.img.
The whole think is kinda hackish...

> -- Pavel
>
>
>



-- 
Sincerely yours,
Mike.