[PATCH v3 00/23] Migration: Transmit and detect zero pages in the multifd threads

Juan Quintela posted 23 patches 2 years, 5 months ago
Test checkpatch passed
Patches applied successfully (tree, apply log)
git fetch https://github.com/patchew-project/qemu tags/patchew/20211124100617.19786-1-quintela@redhat.com
Maintainers: Juan Quintela <quintela@redhat.com>, "Dr. David Alan Gilbert" <dgilbert@redhat.com>
There is a newer version of this series
migration/multifd.h      |  52 +++++++---
migration/migration.c    |   7 +-
migration/multifd-zlib.c |  71 +++++--------
migration/multifd-zstd.c |  70 +++++--------
migration/multifd.c      | 214 +++++++++++++++++++++++----------------
migration/ram.c          |  22 ++--
migration/savevm.c       |   5 +-
migration/trace-events   |   4 +-
8 files changed, 231 insertions(+), 214 deletions(-)
[PATCH v3 00/23] Migration: Transmit and detect zero pages in the multifd threads
Posted by Juan Quintela 2 years, 5 months ago
Hi

Trying with a different server.
As it used to happen, when I sent everything only to me, everything worked.

Sorry folks.

[v2]
This is a rebase against last master.

And the reason for resend is to configure properly git-publish and
hope this time that git-publish send all the patches.

Please, review.

[v1]
Since Friday version:
- More cleanups on the code
- Remove repeated calls to qemu_target_page_size()
- Establish normal pages and zero pages
- detect zero pages on the multifd threads
- send zero pages through the multifd channels.
- reviews by Richard addressed.

It pases migration-test, so it should be perfect O:+)

ToDo for next version:
- check the version changes
  I need that 6.2 is out to check for 7.0.
  This code don't exist at all due to that reason.
- Send measurements of the differences

Please, review.

[

Friday version that just created a single writev instead of
write+writev.

]

Right now, multifd does a write() for the header and a writev() for
each group of pages.  Simplify it so we send the header as another
member of the IOV.

Once there, I got several simplifications:
* is_zero_range() was used only once, just use its body.
* same with is_zero_page().
* Be consintent and use offset insed the ramblock everywhere.
* Now that we have the offsets of the ramblock, we can drop the iov.
* Now that nothing uses iov's except NOCOMP method, move the iovs
  from pages to methods.
* Now we can use iov's with a single field for zlib/zstd.
* send_write() method is the same in all the implementaitons, so use
  it directly.
* Now, we can use a single writev() to write everything.

ToDo: Move zero page detection to the multifd thrteads.

With RAM in the Terabytes size, the detection of the zero page takes
too much time on the main thread.

Last patch on the series removes the detection of zero pages in the
main thread for multifd.  In the next series post, I will add how to
detect the zero pages and send them on multifd channels.

Please review.

Later, Juan.

Juan Quintela (23):
  multifd: Delete useless operation
  migration: Never call twice qemu_target_page_size()
  multifd: Rename used field to num
  multifd: Add missing documention
  multifd: The variable is only used inside the loop
  multifd: remove used parameter from send_prepare() method
  multifd: remove used parameter from send_recv_pages() method
  multifd: Fill offset and block for reception
  multifd: Make zstd compression method not use iovs
  multifd: Make zlib compression method not use iovs
  multifd: Move iov from pages to params
  multifd: Make zlib use iov's
  multifd: Make zstd use iov's
  multifd: Remove send_write() method
  multifd: Use a single writev on the send side
  multifd: Unfold "used" variable by its value
  multifd: Use normal pages array on the send side
  multifd: Use normal pages array on the recv side
  multifd: recv side only needs the RAMBlock host address
  multifd: Rename pages_used to normal_pages
  multifd: Support for zero pages transmission
  multifd: Zero pages transmission
  migration: Use multifd before we check for the zero page

 migration/multifd.h      |  52 +++++++---
 migration/migration.c    |   7 +-
 migration/multifd-zlib.c |  71 +++++--------
 migration/multifd-zstd.c |  70 +++++--------
 migration/multifd.c      | 214 +++++++++++++++++++++++----------------
 migration/ram.c          |  22 ++--
 migration/savevm.c       |   5 +-
 migration/trace-events   |   4 +-
 8 files changed, 231 insertions(+), 214 deletions(-)

-- 
2.33.1



Re: [PATCH v3 00/23] Migration: Transmit and detect zero pages in the multifd threads
Posted by Peter Xu 2 years, 5 months ago
On Wed, Nov 24, 2021 at 11:05:54AM +0100, Juan Quintela wrote:
> Hi
> 
> Trying with a different server.
> As it used to happen, when I sent everything only to me, everything worked.
> 
> Sorry folks.
> 
> [v2]
> This is a rebase against last master.
> 
> And the reason for resend is to configure properly git-publish and
> hope this time that git-publish send all the patches.

I do suffer from this too.  I normally use git-publish parameters "-S" plus
"-R" together when it happens, then in the interactive console selectively send
leftover series to complete previous attempt.

I think it's not a bug for git-publish, but git-send-email with fail with an
SMTP error.  I'm no expert of that, but iirc last time we discussed Paolo
mentioned it could be a git-send-email bug.  Copy Paolo for that in case
there's any further clue out of it.

> 
> Please, review.
> 
> [v1]
> Since Friday version:
> - More cleanups on the code
> - Remove repeated calls to qemu_target_page_size()
> - Establish normal pages and zero pages
> - detect zero pages on the multifd threads
> - send zero pages through the multifd channels.
> - reviews by Richard addressed.
> 
> It pases migration-test, so it should be perfect O:+)

OK I "agree". :-D

Besides, shall we try measure some real workloads?  E.g. total migration time
of an idle guest doing 8 channels multifd migration with/without the patchset?
I'd expect there's a huge speedup on that even with a low speed NIC, and it'll
be great to verify it.

-- 
Peter Xu