On Tue, 11 Mar 2025 at 00:59, Fabiano Rosas <faro...@suse.de> wrote: > Peter Xu <pet...@redhat.com> writes: > > To me, this is a fairly important question to ask. Fundamentally, the very > > initial question is why do we need periodic flush and sync at all. It's > > because we want to make sure new version of pages to land later than old > > versions. ... > > Then v1 and v2 of the page P are ordered. > > If without the message on the main channel: > > Then I don't see what protects reorder of arrival of messages like: ... > That's all fine. As long as the recv part doesn't see them out of > order. I'll try to write some code to confirm so I don't waste too much > of your time.
* Relying on this receive order seems like a passive solution. On one side we are saying there is no defined 'requirement' on the network or compute capacity/quality for migration. ie. compute and network can be as bad as possible, yet migration shall always work reliably. * When receiving different versions of pages, couldn't multifd_recv check the latest version present in guest RAM and accept the incoming version only if it is fresher than the already present one? ie. if v1 arrives later than v2 on the receive side, the receive side could/should discard v1 because v2 is already received. Thank you. --- - Prasad
