On Mon, 10 Feb 2025 at 22:29, Peter Xu <pet...@redhat.com> wrote: > Yes, and I suggest a rename or introduce a new helper, per previous reply.
* Okay, will try it. > I didn't follow, sorry - do you mean this patch is correct on dropping the > mapped-ram check? I don't yet understand how it can work if without. * It goes for channel peek if '!migrate_mapped_ram', ie. when mapped_ram is not set. When it is enabled, likely it just falls into the multifd channel, like other tls/file channels. I'll see if we have to add a check for mapped_ram stream, like tls/file one. > I meant tls channels should have these magics too. Do you mean they're not? * Yes. AFAIU, tls/file channels don't send magic values. > No I don't think so. > Flushing sending side makes sure send buffer is empty. It doesn't > guarantee recv buffer is empty on the other side. * A simple 'flush' operation is not supposed to guarantee reception on the destination side. It is just a 'flush' operation. If we want to _confirm_ whether the pages sent to the destination are received or not, then the destination side should send an 'Acknowledgement' to the source side. Is there such a mechanism in place currently? > > > > * If all multifd pages are sent/written/flushed onto the multifd > > channels before postcopy_start() is called, then multifd pages should > > not arrive at the destination after postcopy starts IIUC. If that is > > happening, we need a reproducer for such a case. Do we have such a > > reproducer? > > With or without a reproducer, we need to at least justify it in theory. If > it doesn't even work in theory, it's a problem. * The theory that both multifd and postcopy channels use the same underlying network wire; And in that multifd pages get delayed, but postcopy pages don't, is not understandable. There must be something else happening in such a case, which a reproducer could help with. Thank you. --- - Prasad
