It takes too long on Restoring images

[huangyabin001]

Description when restoring the images,it takes around 4s;

Steps to reproduce the issue: 1.dump the process by command "criu dump -v4 -t pid_xxx --leave-running -D /criu --ext-unix-sk" 2.restore the process by command "criu restore -v2 -D /criu --ext-unix-sk --restore-detached --restore-sibling" 3.then the issue could absolutely occur;

Describe the results you received: the duration of the restoring could take around 4 seconds

Describe the results you expected: we used "dd" command to read the same image, it just takes 0.5 second, so i expect the result should approximate the speed of "dd" command the full "dd" command we use is "dd if=/criu/xxxxxx.img of=/dev/null bs=50M count=1"

Additional information you deem important (e.g. issue happens only occasionally):

CRIU logs and information:

CRIU full dump/restore logs:

restore logs:
......
(01.678972) pie: 4618: 	mmap(0xffffadae2000 -> 0xffffadae3000, 0x3 0x12 243)
(01.678983) pie: 4618: 	mmap(0xffffadae3000 -> 0xffffadae4000, 0x3 0x32 -1)
(01.678992) pie: 4618: 	mmap(0xffffe1e16000 -> 0xffffe1e37000, 0x3 0x132 -1)
(01.679002) pie: 4618: Preadv 0x24e80000:262144... (491 iovs)
(05.616909) pie: 4618: `- returned 27918336
(05.617123) pie: 4618:    `- skip pagemap
(05.617136) pie: 4618:    `- skip pagemap
......

Output of `criu --version`:

criu --version
Version: 3.13

Output of `criu check --all`:

criu check --all
Warn  (third_party/criu/criu-3.13/criu/log.c:203): The early log isn't empty
Warn  (third_party/criu/criu-3.13/criu/cr-check.c:850): Dirty tracking is OFF. Memory snapshot will not work.
Error (third_party/criu/criu-3.13/criu/cr-check.c:1169): No userns proc file: No such file or directory
Warn  (third_party/criu/criu-3.13/criu/cr-check.c:1231): Do not have API to map vDSO - will use mremap() to restore vDSO
Error (third_party/criu/criu-3.13/criu/cr-check.c:1207): UFFD is not supported
Error (third_party/criu/criu-3.13/criu/cr-check.c:1207): UFFD is not supported
Error (third_party/criu/criu-3.13/criu/cr-check.c:1033): failed to mount autofs: No such device
Warn  (third_party/criu/criu-3.13/criu/cr-check.c:1199): CRIU built without CONFIG_COMPAT - can't C/R compatible tasks
Looks good but some kernel features are missing
which, depending on your process tree, may cause
dump or restore failure.

Additional environment details:

[avagin]

could you try to run criu restore with -v0 ...?

[huangyabin001]

ok,i'll try to restorre with -v0.and feedback later.thanks,avagin;

[huangyabin001]

i tried,and it did'n work;

[avagin]

could you try to run "perf trace -Sfo perf.log criu restore ..." and share the perf.log file with us?

[rst0git]

we used "dd" command to read the same image, it just takes 0.5 second

dd would only read the image, criu needs to do more than that to restore the process tree.

You can get some useful information from the stats-restore file with crit show stats-restore.

If you are interested in this topic, you check the optimization technique proposed in https://doi.org/10.1145/3357526.3357542

Alternatively, you can minimise the restore time with post-copy migration (https://criu.org/Lazy_migration).

[github-actions[bot]]

A friendly reminder that this issue had no activity for 30 days.