Re: [Qemu-devel] [PATCH v6 19/19] migration: Flush receive queue

[Peter Xu]

On Tue, Aug 08, 2017 at 06:26:29PM +0200, Juan Quintela wrote:
> Each time that we sync the bitmap, it is a possiblity that we receive
> a page that is being processed by a different thread.  We fix this
> problem just making sure that we wait for all receiving threads to
> finish its work before we procedeed with the next stage.
> 
> We are low on page flags, so we use a combination that is not valid to
> emit that message:  MULTIFD_PAGE and COMPRESSED.
> 
> I tried to make a migration command for it, but it don't work because
> we sync the bitmap sometimes when we have already sent the beggining
> of the section, so I just added a new page flag.
> 
> Signed-off-by: Juan Quintela <address@hidden>

Oh, I just pop up an idea on whether we can just avoid introduing the
new flush command...

Can we just hash the page address into the channel number we send?
Then if we are sending the same page, it will always be on the same
channel. Since it's on the same channel, the order of arrival is also
deterministic.

It may affect performance, at least in two ways:

- it can be slower, considering we may need to wait on specific
  channel when send. But it may not be a big problem since we have a
  local IOV array buffer, then when the array buffer is full, the old
  send() should mostly be completed I guess.

- it can be faster, considering that we don't need the flush any more,
  so receiving is faster (no need to wait for all the channels to
  complete on flush).

Makes any sense?

-- 
Peter Xu