Re: [PATCH v4 2/7] migration/multifd: Implement zero page transmission on the multifd thread.

[Fabiano Rosas]

Fabiano Rosas <farosas@suse.de> writes:

> Fabiano Rosas <farosas@suse.de> writes:
>
>> Peter Xu <peterx@redhat.com> writes:
>>
>>> On Fri, Mar 01, 2024 at 02:28:24AM +0000, Hao Xiang wrote:
>>>> -GlobalProperty hw_compat_8_2[] = {};
>>>> +GlobalProperty hw_compat_8_2[] = {
>>>> +    { "migration", "zero-page-detection", "legacy"},
>>>> +};
>>>
>>> I hope we can make it for 9.0, then this (and many rest places) can be kept
>>> as-is.  Let's see..  soft-freeze is March 12th.
>>>
>>> One thing to mention is I just sent a pull which has mapped-ram feature
>>> merged.  You may need a rebase onto that, and hopefully mapped-ram can also
>>> use your feature too within the same patch when you repost.
>>
>> The key points are:
>>
>> - The socket migration is under "use_packets", the mapped-ram is under
>> "!use_packets" always.
>>
>> - mapped-ram doesn't trasmit zero-pages, it just clears the
>> corresponding bit in block->file_bmap.
>>
>>> https://lore.kernel.org/all/20240229153017.2221-1-farosas@suse.de/
>>>
>>> That rebase may or may not need much caution, I apologize for that:
>>> mapped-ram as a feature was discussed 1+ years, so it was a plan to merge
>>> it (actually still partly of it) into QEMU 9.0.
>>
>> I started doing that rebase last week and saw issues with a sender
>> thread always getting -EPIPE at the sendmsg() on the regular socket
>> migration. Let's hope it was just me being tired. I'll try to get
>> something ready this week.
>
> This was just a rebase mistake.
>
> While debugging it I noticed that migration-test doesn't really test
> zero page code properly. The guest workload dirties all memory right
> away, so I'm not sure we ever see a zero page. A quick test with
> multifd, shows p->zero_num=0 all the time.
>
> Any ideas on how to introduce some holes for zero page testing?

Aaaand that's another mistake on my part. Scratch that. The tests work
just fine.