[CRIU] Questions in CRIU restore mechanism.

Tue Mar 26 08:27:39 EDT 2013

> -----Original Message-----
> From: Alexander Kartashov [mailto:alekskartashov at parallels.com]
> Sent: Monday, March 25, 2013 10:12 PM
> To: myungjoo.ham
> Cc: jh80.chung at samsung.com; chanho61.park at samsung.com;
> hj210.choi at samsung.com; crml
> Subject: Re: [CRIU] Questions in CRIU restore mechanism.
> 
> 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.
> >
> >> 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.
> What compilation errors do you get?

Hi,
I had below compilation error during build crtools

[  121s] gcc -c -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions
--param=ssp-buffer-size=4 -Wformat -Wformat-security -fmessage-length=0
-march=armv7-a -mtune=cortex-a8 -mlittle-endian -mfpu=vfpv3
-mfloat-abi=softfp -D__SOFTFP__ -mthumb -Wa,-mimplicit-it=thumb
-march=armv7-a -O2 -Wall -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -iquote
include -iquote pie -iquote . -iquote arch/arm -iquote arch/arm/include
-fno-strict-aliasing -DCR_NOGLIBC -fpie  -Wa,--noexecstack
-fno-stack-protector  pie/util-net.c -o pie/util-net.o
[  121s] ld -r -o pie/parasite.built-in.o pie/parasite.o
arch/arm/parasite-head.o pie/log-simple.o pie/util-net.o
arch/arm/syscalls.built-in.o
[  121s] bash -c "echo 'OUTPUT_ARCH(arm)'	 > pie/pie.lds.S"
[  121s] bash -c "cat pie/pie.lds.S.in		>> pie/pie.lds.S"
[  121s] ld -T pie/pie.lds.S -o pie/parasite.built-in.bin.o
pie/parasite.built-in.o
[  121s] `_GLOBAL_OFFSET_TABLE_' referenced in section `.text' of
pie/parasite.built-in.o: defined in discarded section `.got.plt' of
pie/parasite.built-in.o
[  121s] `_GLOBAL_OFFSET_TABLE_' referenced in section `.text' of
pie/parasite.built-in.o: defined in discarded section `.got.plt' of
pie/parasite.built-in.o
[  121s] `_GLOBAL_OFFSET_TABLE_' referenced in section `.text' of
pie/parasite.built-in.o: defined in discarded section `.got.plt' of
pie/parasite.built-in.o
[  121s] `_GLOBAL_OFFSET_TABLE_' referenced in section `.text' of
pie/parasite.built-in.o: defined in discarded section `.got.plt' of
pie/parasite.built-in.o
[  121s] `_GLOBAL_OFFSET_TABLE_' referenced in section `.text' of
pie/parasite.built-in.o: defined in discarded section `.got.plt' of
pie/parasite.built-in.o
[  121s] `_GLOBAL_OFFSET_TABLE_' referenced in section `.text' of
pie/parasite.built-in.o: defined in discarded section `.got.plt' of
pie/parasite.built-in.o
[  121s] make[1]: *** [pie/parasite.built-in.bin.o] Error 1
[  121s] make: *** [pie] Error 2
[  121s] error: Bad exit status from /var/tmp/rpm-tmp.A8KWxB (%build)

Our gcc and glibc version is as follow:
GNU C Library (EGLIBC) stable release version 2.13, by Roland McGrath et al.
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.5.3.
Compiled on a Linux 2.6.36 system on 2013-03-19.
Available extensions:
	crypt add-on version 2.1 by Michael Glad and others
	GNU Libidn by Simon Josefsson
	Native POSIX Threads Library by Ulrich Drepper et al
	Support for some architectures added on, not maintained in glibc
core.
	BIND-8.2.3-T5B
libc ABIs: UNIQUE
For bug reporting instructions, please see:
<http://www.eglibc.org/issues/>.

When I compiled with gcc-linaro 4.7 compiler, everything is OK.
However, our compiler complained as you see.
I found [1] patch related with the error.
Should we upgrade or patch binutils or glibc?

[1] : http://permalink.gmane.org/gmane.comp.gnu.binutils/49684

Thanks,

Best Regards,
Chanho Park

> >   I was wondering if there are some example configuration for building
> CRIU in your git or web pages.
> There's no special CRIU configuration for ARM. It should be compiled
> successfully just by issuing make.
> >
> >
> > Thank you so much!
> >
> >
> > Cheers,
> > MyungJoo
> >
> >
> >
> > _______________________________________________
> > CRIU mailing list
> > CRIU at openvz.org
> > https://lists.openvz.org/mailman/listinfo/criu
> 
> 
> --
> Sincerely yours,
> Alexander Kartashov
> 
> Intern
> Core team
> 
> www.parallels.com
> 
> Skype: aleksandr.kartashov
> Email: alekskartashov at parallels.com