qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Orit Wasserman <owasserm@redhat.com>
Cc: pbonzini@redhat.com, chegu_vinod@hp.com, qemu-devel@nongnu.org,
	quintela@redhat.com
Subject: Re: [Qemu-devel] [RFC 00/12] Migration: Remove copying of guest ram pages
Date: Thu, 21 Mar 2013 11:48:19 +0200	[thread overview]
Message-ID: <20130321094818.GH28328@redhat.com> (raw)
In-Reply-To: <1363856971-4601-1-git-send-email-owasserm@redhat.com>

On Thu, Mar 21, 2013 at 11:09:19AM +0200, Orit Wasserman wrote:
> In migration all data is copied to a static buffer in QEMUFile,
> this hurts our network bandwidth and CPU usage especially with large guests.
> We switched to iovec for storing different buffers to send (even a byte field is
> considered as a buffer) and use writev to send the iovec.
> writev was chosen (as apposed to sendmsg) because it supprts non socket fds.
>   
> Guest memory pages are not copied by calling a new function 
> qemu_put_buffer_no_copy.
> The page header data and device state data are still copied into the static
> buffer. This data consists of a lot of bytes and integer fields and the static
> buffer is used to store it during batching.
> Another improvement is changing qemu_putbe64/32/16 to create a single
> buffer instead of several byte sized buffer.

A recent discussion about overcommitted memory made me think:
this will still need to read pages into memory even
if all we will do is send it out on the wire immediately,
dirtying cache etc.

Now, one property of RAM writes is that if guest changes
the memory that we are migrating, we really
don't care that remote will get a new copy and not
the old copy.

So this seems like a perfect place to use vmsplice
and save the read of data from pagecache into QEMU.

For this to work, however, we need to have a way
for QEMUFile to know whether a specific iovec
references RAM (so it's ok to use vmsplice)
or a malloced buffer for device state (so it must use write
to ensure kernel copies data).

What do you think?

> Orit Wasserman (12):
>   Add iov_writev to use writev to send iovec (also for files)
>   Add QemuFileWritevBuffer QemuFileOps
>   Add socket_writev_buffer function
>   Add stdio_writev_buffer function
>   Add block_writev_buffer function
>   Update bytes_xfer in qemu_put_byte
>   Store the data to send also in iovec
>   Use writev ops instead of put_buffer ops
>   More optimized qemu_put_be64/32/16
>   Add qemu_put_buffer_no_copy
>   Use qemu_put_buffer_no_copy for guest memory pages
>   Bye Bye put_buffer
> 
>  arch_init.c                   |   2 +-
>  include/migration/qemu-file.h |  20 ++++---
>  include/qemu/iov.h            |  12 ++++
>  savevm.c                      | 130 +++++++++++++++++++++++++-----------------
>  util/iov.c                    |  36 ++++++++++++
>  5 files changed, 139 insertions(+), 61 deletions(-)
> 
> -- 
> 1.7.11.7

  parent reply	other threads:[~2013-03-21  9:47 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-21  9:09 [Qemu-devel] [RFC 00/12] Migration: Remove copying of guest ram pages Orit Wasserman
2013-03-21  9:09 ` [Qemu-devel] [RFC 01/12] Add iov_writev to use writev to send iovec (also for files) Orit Wasserman
2013-03-21  9:23   ` Paolo Bonzini
2013-03-21  9:09 ` [Qemu-devel] [RFC 02/12] Add QemuFileWritevBuffer QemuFileOps Orit Wasserman
2013-03-21  9:09 ` [Qemu-devel] [RFC 03/12] Add socket_writev_buffer function Orit Wasserman
2013-03-21  9:18   ` Paolo Bonzini
2013-03-21  9:47     ` Orit Wasserman
2013-03-21  9:47       ` Paolo Bonzini
2013-03-21 10:17         ` Orit Wasserman
2013-03-21  9:09 ` [Qemu-devel] [RFC 04/12] Add stdio_writev_buffer function Orit Wasserman
2013-03-21  9:28   ` Paolo Bonzini
2013-03-21  9:09 ` [Qemu-devel] [RFC 05/12] Add block_writev_buffer function Orit Wasserman
2013-03-21  9:09 ` [Qemu-devel] [RFC 06/12] Update bytes_xfer in qemu_put_byte Orit Wasserman
2013-03-21  9:09 ` [Qemu-devel] [RFC 07/12] Store the data to send also in iovec Orit Wasserman
2013-03-21  9:56   ` Paolo Bonzini
2013-03-21 11:10     ` Orit Wasserman
2013-03-21 11:14       ` Michael S. Tsirkin
2013-03-21 12:50         ` Orit Wasserman
2013-03-21 13:00           ` Paolo Bonzini
2013-03-21  9:09 ` [Qemu-devel] [RFC 08/12] Use writev ops instead of put_buffer ops Orit Wasserman
2013-03-21  9:09 ` [Qemu-devel] [RFC 09/12] More optimized qemu_put_be64/32/16 Orit Wasserman
2013-03-21  9:09 ` [Qemu-devel] [RFC 10/12] Add qemu_put_buffer_no_copy Orit Wasserman
2013-03-21  9:25   ` Paolo Bonzini
2013-03-23 16:27   ` Michael R. Hines
2013-03-25  8:11     ` Orit Wasserman
2013-03-25 13:05     ` Paolo Bonzini
2013-03-25 15:18       ` Michael R. Hines
2013-03-25 15:59         ` Paolo Bonzini
2013-03-21  9:09 ` [Qemu-devel] [RFC 11/12] Use qemu_put_buffer_no_copy for guest memory pages Orit Wasserman
2013-03-21  9:09 ` [Qemu-devel] [RFC 12/12] Bye Bye put_buffer Orit Wasserman
2013-03-21  9:29 ` [Qemu-devel] [RFC 00/12] Migration: Remove copying of guest ram pages Paolo Bonzini
2013-03-21 10:05   ` Orit Wasserman
2013-03-21  9:48 ` Michael S. Tsirkin [this message]
2013-03-21  9:53   ` Paolo Bonzini
2013-03-21 11:09     ` Michael S. Tsirkin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130321094818.GH28328@redhat.com \
    --to=mst@redhat.com \
    --cc=chegu_vinod@hp.com \
    --cc=owasserm@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=quintela@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).