All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Juan Quintela <quintela@redhat.com>
Cc: Orit Wasserman <owasserm@redhat.com>,
	chegu_vinod@hp.com, qemu-devel@nongnu.org, pbonzini@redhat.com
Subject: Re: [Qemu-devel] [PATCH v3 9/9] coalesce adjacent iovecs
Date: Thu, 21 Mar 2013 19:46:35 +0200	[thread overview]
Message-ID: <20130321174635.GA4112@redhat.com> (raw)
In-Reply-To: <877gl0ps0h.fsf@elfo.elfo>

On Thu, Mar 21, 2013 at 06:44:14PM +0100, Juan Quintela wrote:
> "Michael S. Tsirkin" <mst@redhat.com> wrote:
> > On Thu, Mar 21, 2013 at 06:27:42PM +0200, Orit Wasserman wrote:
> >> On 03/21/2013 06:16 PM, Michael S. Tsirkin wrote:
> >> > On Thu, Mar 21, 2013 at 06:05:40PM +0200, Orit Wasserman wrote:
> >> >> This way we send one big buffer instead of many small ones
> >> >>
> >> >> Signed-off-by: Orit Wasserman <owasserm@redhat.com>
> >> > 
> >> > Why does this happen BTW?
> >> 
> >> It happens in the last phase when we send the device state that
> >> consists of a lot
> >> bytes and int field that are written using qemu_put_byte/be16/...
> >> 
> >
> > Confused  I thought device_state does not use _nocopy?
> > My idea of using vmsplice relies exactly on this:
> > we can not splice device state ...
> 
> 
> As it is today, I am not sure that we can use vmsplice() because we
> are sending:
> 
> 
> <header>
> <page>
> <header>
> <page>
> <header>
> <page>
> 
> We can optimize at some pount to write a bigger/different header and
> sent a bunch of pages together, but just now we don't have that code.
> 
> Later, Juan.

Sending the page can do vmsplice, can't it?
Multipage is likely a good idea anyway, e.g. RDMA wants to
do this too.

  reply	other threads:[~2013-03-21 17:46 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-21 16:05 [Qemu-devel] [PATCH v3 0/9] Migration: Remove copying of guest ram pages Orit Wasserman
2013-03-21 16:05 ` [Qemu-devel] [PATCH v3 1/9] Add QemuFileWritevBuffer QemuFileOps Orit Wasserman
2013-03-21 16:57   ` Juan Quintela
2013-03-21 16:05 ` [Qemu-devel] [PATCH v3 2/9] Add socket_writev_buffer function Orit Wasserman
2013-03-21 16:55   ` Juan Quintela
2013-03-21 16:05 ` [Qemu-devel] [PATCH v3 3/9] Update bytes_xfer in qemu_put_byte Orit Wasserman
2013-03-21 17:06   ` Juan Quintela
2013-03-21 17:38   ` Eric Blake
2013-03-21 17:41     ` Orit Wasserman
2013-03-21 16:05 ` [Qemu-devel] [PATCH v3 4/9] Store the data to send also in iovec Orit Wasserman
2013-03-21 17:11   ` Juan Quintela
2013-03-21 16:05 ` [Qemu-devel] [PATCH v3 5/9] Use writev ops if available Orit Wasserman
2013-03-21 17:17   ` Juan Quintela
2013-03-21 16:05 ` [Qemu-devel] [PATCH v3 6/9] More optimized qemu_put_be64/32/16 Orit Wasserman
2013-03-21 17:18   ` Juan Quintela
2013-03-21 16:05 ` [Qemu-devel] [PATCH v3 7/9] Add qemu_put_buffer_no_copy Orit Wasserman
2013-03-21 17:34   ` Juan Quintela
2013-03-21 17:39     ` Orit Wasserman
2013-03-21 16:05 ` [Qemu-devel] [PATCH v3 8/9] Use qemu_put_buffer_no_copy for guest memory pages Orit Wasserman
2013-03-21 16:14   ` Michael S. Tsirkin
2013-03-21 17:37   ` Juan Quintela
2013-03-21 18:08     ` Orit Wasserman
2013-03-21 18:21       ` Michael S. Tsirkin
2013-03-21 16:05 ` [Qemu-devel] [PATCH v3 9/9] coalesce adjacent iovecs Orit Wasserman
2013-03-21 16:16   ` Michael S. Tsirkin
2013-03-21 16:27     ` Orit Wasserman
2013-03-21 16:29       ` Michael S. Tsirkin
2013-03-21 16:40         ` Orit Wasserman
2013-03-21 17:10           ` Michael S. Tsirkin
2013-03-21 17:44         ` Juan Quintela
2013-03-21 17:46           ` Michael S. Tsirkin [this message]
2013-03-21 18:22             ` Juan Quintela
2013-03-21 18:33               ` Michael S. Tsirkin
2013-03-21 17:41   ` Juan Quintela
2013-03-21 17:12 ` [Qemu-devel] [PATCH v3 0/9] Migration: Remove copying of guest ram pages Paolo Bonzini
2013-03-21 17:35   ` Orit Wasserman
2013-03-21 17:42 ` Juan Quintela

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=20130321174635.GA4112@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.