Peter Xu <pet...@redhat.com> wrote:
> On Wed, Feb 15, 2023 at 07:02:31PM +0100, Juan Quintela wrote:
>> We need to add a new flag to mean to flush at that point.
>> Notice that we still flush at the end of setup and at the end of
>> complete stages.
>>
>> Signed-off-by: Juan Quintela <quint...@redhat.com>
>
> Acked-by: Peter Xu <pet...@redhat.com>
>
> One nitpick below.
Thanks.
>> @@ -4169,7 +4190,9 @@ int ram_load_postcopy(QEMUFile *f, int channel)
>> }
>> decompress_data_with_multi_threads(f, page_buffer, len);
>> break;
>> -
>> + case RAM_SAVE_FLAG_MULTIFD_FLUSH:
>> + multifd_recv_sync_main();
>> + break;
>> case RAM_SAVE_FLAG_EOS:
>> /* normal exit */
>> if (migrate_multifd_flush_after_each_section()) {
>
> We could have dropped RAM_SAVE_FLAG_MULTIFD_FLUSH and RAM_SAVE_FLAG_EOS for
> now until we support postcopy+multifd.
I don't think so.
We have this curse of biblic proportions called Backwards compatibility.
We need to mark the beggining and end of sections. That is independent
of multifd.
And for multifd we have to flush all channels at the end of each
iteration through RAM. We could do that without involving the main
thread, but I don't see the point of doing that.
> Here it's not only about enabling them together, but it's about running
> them in parallel, which I doubt whether it can really be implemented at all
> due to the fundamentally concepts difference between multifd & postcopy.. :(
Later, Juan.
