Prasad Pandit <ppan...@redhat.com> writes: > 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. >
"in guest RAM" I don't think so, the performance would probably be affected. We could have a sequence number that gets bumped per iteration, but I'm not sure how much of a improvement that would be. Without a sync, we'd need some sort of per-page handling*. I have a gut feeling this would get costly. *- maybe per-iovec depending on how we queue pages to multifd. > Thank you. > --- > - Prasad
