From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:41274) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIdMK-00023d-JB for qemu-devel@nongnu.org; Thu, 21 Mar 2013 07:08:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1UIdMG-0000iS-HP for qemu-devel@nongnu.org; Thu, 21 Mar 2013 07:08:36 -0400 Received: from mx1.redhat.com ([209.132.183.28]:41335) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1UIdMG-0000iC-8o for qemu-devel@nongnu.org; Thu, 21 Mar 2013 07:08:32 -0400 Date: Thu, 21 Mar 2013 13:09:10 +0200 From: "Michael S. Tsirkin" Message-ID: <20130321110910.GB24024@redhat.com> References: <1363856971-4601-1-git-send-email-owasserm@redhat.com> <20130321094818.GH28328@redhat.com> <514AD8B3.8060901@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <514AD8B3.8060901@redhat.com> Subject: Re: [Qemu-devel] [RFC 00/12] Migration: Remove copying of guest ram pages List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Orit Wasserman , chegu_vinod@hp.com, qemu-devel@nongnu.org, quintela@redhat.com On Thu, Mar 21, 2013 at 10:53:55AM +0100, Paolo Bonzini wrote: > Il 21/03/2013 10:48, Michael S. Tsirkin ha scritto: > > 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. > > Orit's patches already do this (patch 11). The only copy that remains > is from memory to socket buffers. > > > > 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? > > Was SPLICE_F_GIFT/SPLICE_F_MOVE ever implemented in the end? If not, > patch 11 of this series does the same thing you are suggesting, without > the indirection of an additional pipe file descriptor that is required > for splice/vmsplice. > > Paolo GIFT seems to be implemented so no problem there. MOVE seems not to be needed for TCP - I think it just uses sendpage internally which will do zero copy without special hints. > >> 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