[CRIU] Questions in CRIU restore mechanism.

Pavel Emelyanov xemul at parallels.com
Mon Mar 25 09:04:35 EDT 2013


On 03/25/2013 04:59 PM, myungjoo.ham wrote:
>>
>> On 03/25/2013 11:47 AM, MyungJoo Ham wrote:
>>> Samsung Enterprise Portal mySingle
>>>
>>> Hello, CRIU developers and maintainers.
>>>
>>> Thank you for your wonderful project being released to public including ARM.
>>
>> You're welcome.
>>
>>>
>>> I have a question on the CRIU restore mechanism while trying to use 
>>> CRIU to accelerate launching of large user processes.
>>>
>>> Q1: Does CRIU support "demand paging"-like restore?
>>>
>>> (Not restoring the whole process image to RAM at once, but restoring 
>>> pages wanted  by the process from disk to RAM like the swap-in 
>>> mechanism usually does)
>>
>> The answer is both -- yes and no. There are 4 types of mappings application may use:
>> shared anon, shared file, private anon and private file.
>>
>> For shared file mappings we don't restore pages contents at all, since the contents of the pages is in the respective file and if app after restore will try to read them it will read the data from disk (just as you want).
> 
> This is great.
> 
> As long as we can put prefetch-style background paging, this should be a big help on
> user process launching speed-up.

Yup. This makes perfect sense.

I'd like to note, that the CRIU project is open for new functionality, so if you
can contribute this background-prefetch to CRIU, that would be awesome!

>> For shared anon and private anon mappings we do restore contents of pages from image.
>> This can't be fixed at the moment, since the kernel currently doesn't provide any APIs for fixing this.
>>
>> For private file mappings situation is tricky. Withing these mappings there are two types of pages -- those, that were read from file and modified, and those that were just read, but not modified. So the former pages cannot be restored-on-demand for the same reasons as anon mappings cannot be. Latter pages are not restored, since the data app want is in the file and it will work like it does for shared file mappings.
>>
>>> Q2: Would it be possible to set the CRIU process image as a swap file 
>>> and let Linux kernel use it (supporting Q1)?
>>
>> It's a good idea. Yes, this is possible, but only in theory -- kernel doesn't have any APIs for telling "make this virtual address be mapped to this swap entry". If we had one, we could do this.
>>
>>> Q3: Any example configuration or script for ARM port of CRIU?
>>
>> I don't get this question. Can you elaborate, please?
> 
> Me and my collegues have been trying to build CRIU+ProtoBuf for ARM targets with no success 
> today. I was wondering if there are some example configuration for building CRIU in your git 
> or web pages.

The http://criu.org/Installation is the best we have. Please, address your questions here to the
mailing-list, we'll provide help (and will improve the page :) ).

> 
> Thank you so much!

MyungJoo, can you elaborate a little bit more on the project you're working on? We're interested
in how CRIU is used and if you cane share this info, this would be great!

> 
> Cheers,
> MyungJoo

Thanks,
Pavel


More information about the CRIU mailing list