[CRIU] bug in shmem restore?

[Pavel Tikhomirov]

On 06/24/2016 09:55 AM, Mike Rapoport wrote:
>
> On Jun 24, 2016 9:37 AM, "Andrei Vagin" <avagin at gmail.com
> <mailto:avagin at gmail.com>> wrote:
>>
>> On Thu, Jun 23, 2016 at 10:45 PM, Mike Rapoport
> <mike.rapoport at gmail.com <mailto:mike.rapoport at gmail.com>> wrote:
>> >
>> > On Jun 24, 2016 4:23 AM, "Andrew Vagin" <avagin at virtuozzo.com
> <mailto:avagin at virtuozzo.com>> wrote:
>> >>
>> >> On Thu, Jun 23, 2016 at 11:31:04AM +0300, Mike Rapoport wrote:
>> >> > Hi,
>> >> >
>> >> > I've been looking into reducing use of page-read  internals outside
>> >> > the page-read.c and found something that seems really weird.
>> >> >
>> >> > If auto_dedup is enabled, the restore_shmem_content punches a hole in
>> >> > the  pagemap image, but it never tries to read anything from the
>> >> > parent image. Moreover, open_page_read_at does not even bother to
> open
>> >> > parent image in case it opens shared memory image.
>> >> >
>> >> > If I understand correctly, if the hole is really punched, calling
>> >> > restore next time on the same set of images will fail.
>> >>
>> >> if you use --auto-dedup, you are going to run restore only once
>> >
>> > And what if I'd like to use the same checkpoint directories once
> more, e.g.
>> > on another host?
>>
>> Maybe you have to run criu without the --auto-dedup option in this case?
>
> And what's the point of auto-dedup then?

auto-dedup on process restore is made to cleanup pages in images as soon 
as they(pages) are already restored in processes memory(as explained 
below). That can be used for instance then images lay on tmpfs to 
prevent doubling the memory usage on restore. We can put images on tmpfs 
to improve migration speed.

>
>> >
>> >>   --auto-dedup          when used on dump it will deduplicate "old"
> data
>> >> in
>> >>                         pages images of previous dump
>> >>                         when used on restore, as soon as page is
> restored,
>> >> it
>> >>                         will be punched from the image.
>> >>
>> >> >
>> >> > Am I missing something?
>> >> >
>> >> > --
>> >> > Sincerely yours,
>> >> > Mike.
>> >> > _______________________________________________
>> >> > CRIU mailing list
>> >> > CRIU at openvz.org <mailto:CRIU at openvz.org>
>> >> > https://lists.openvz.org/mailman/listinfo/criu
>> >
>> >
>> > _______________________________________________
>> > CRIU mailing list
>> > CRIU at openvz.org <mailto:CRIU at openvz.org>
>> > https://lists.openvz.org/mailman/listinfo/criu
>> >
>

-- 
Best regards, Tikhomirov Pavel
Software Developer, Virtuozzo.