Re: [Qemu-devel] [PATCH 17/17] migration: flush receive queue

[Juan Quintela <quintela@redhat.com>]

"Dr. David Alan Gilbert" <dgilbert@redhat.com> wrote:
> * Juan Quintela (quintela@redhat.com) wrote:
>> Each time that we sync the bitmap, it is a possiblity that we receive
>> a page that is being processed by a different thread.  We fix this
>> problem just making sure that we wait for all receiving threads to
>> finish its work before we procedeed with the next stage.
>> 
>> We are low on page flags, so we use a combination that is not valid to
>> emit that message:  MULTIFD_PAGE and COMPRESSED.
>> 
>> I tried to make a migration command for it, but it don't work because
>> we sync the bitmap sometimes when we have already sent the beggining
>> of the section, so I just added a new page flag.
>> 
>> Signed-off-by: Juan Quintela <quintela@redhat.com>
>
> Is there something that makes sure that the very last page is marked
> with a flush to ensure that the read completes before we start
> trying to do anything after ram_load ?
> As I read this the flag gets added to the first page of the next round.

Yes.  It is easier.  We handle this flag before we handle the following
page, so it is safe, no?

>> 
>> +        if ((flags & (RAM_SAVE_FLAG_MULTIFD_PAGE|RAM_SAVE_FLAG_COMPRESS))
>> +                  == (RAM_SAVE_FLAG_MULTIFD_PAGE|RAM_SAVE_FLAG_COMPRESS)) {
>> +            multifd_flush();
>> +            flags = flags & ~RAM_SAVE_FLAG_COMPRESS;
>> +        }
>>          if (flags & (RAM_SAVE_FLAG_COMPRESS | RAM_SAVE_FLAG_PAGE |
>>                       RAM_SAVE_FLAG_COMPRESS_PAGE | RAM_SAVE_FLAG_XBZRLE |
>>                       RAM_SAVE_FLAG_MULTIFD_PAGE)) {

Here is where we make sure than we have done.

<think, think , think ...>

Ok,  I think what you mean, what we do for the last page of the last
round.  Will try to move it to the place that you asked for.  Not
trivial because we generate the header before we do anything else, and
the last page could not be a multifd one.  Will think about it.

Thanks, Juan.


>> -- 
>> 2.9.3
>> 
> --
> Dr. David Alan Gilbert / dgilbert@redhat.com / Manchester, UK