qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org,
	"Michael R. Hines" <mrhines@linux.vnet.ibm.com>,
	owasserm@redhat.com, abali@us.ibm.com, mrhines@us.ibm.com,
	gokul@us.ibm.com
Subject: Re: [Qemu-devel] [RFC PATCH RDMA support v1: 10/13] introduce new command migrate_check_for_zero
Date: Thu, 11 Apr 2013 17:45:34 +0300	[thread overview]
Message-ID: <20130411144534.GE24942@redhat.com> (raw)
In-Reply-To: <5166C59A.4010904@redhat.com>

On Thu, Apr 11, 2013 at 04:15:54PM +0200, Paolo Bonzini wrote:
> Il 11/04/2013 15:24, Michael R. Hines ha scritto:
> > That's very accurate. Zero page scanning *after* the bulk phase
> > is not very helpful in general.
> > 
> > Are we proposing to skip is_dup_page() after the bulk phase
> > has finished?
> 
> No, I'm saying that is_dup_page() should not be a problem.  I'm saying
> it should only loop a lot during the bulk phase.  The only effect I can
> imagine after the bulk phase is one cache miss.
> 
> Perhaps the stress-test you're using does not reproduce realistic
> conditions with respect to zero pages.  Peter Lieven benchmarked real
> guests, both Linux and Windows, and confirmed the theory that I
> mentioned upthread.  Almost all non-zero pages are detected within the
> first few words, and almost all zero pages come from the bulk phase.
> 
> Considering that one cache miss, RDMA is indeed different here.  TCP
> would have this cache miss later anyway, RDMA does not.  Let's say 300
> cycles/miss; at 2.5 GHz that is 300/2500 microseconds, i.e 0.12
> microseconds per page.  This would say that we can run is_dup_page on 30
> GB worth of nonzero pages every second or more.  Ok, the estimate is
> quite generous in many ways, but is_dup_page() is only a bottleneck if
> it can do less than 5 GB/s.
> 
> Paolo

Further, if we read the pagemap to detect duplicates,
we won't need to read the page for RDMA either.
This might or might not prove to be a win, but
one thing for sure, management will not be able
to know if it's a win.

-- 
MST

  reply	other threads:[~2013-04-11 14:47 UTC|newest]

Thread overview: 52+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-04-10 22:28 [Qemu-devel] [RFC PATCH RDMA support v7: 00/13] rdma cleanup and reordering mrhines
2013-04-10 22:28 ` [Qemu-devel] [RFC PATCH RDMA support v1: 01/13] introduce qemu_ram_foreach_block() mrhines
2013-04-10 22:28 ` [Qemu-devel] [RFC PATCH RDMA support v1: 02/13] Core RMDA logic mrhines
2013-04-10 22:28 ` [Qemu-devel] [RFC PATCH RDMA support v1: 03/13] RDMA is enabled by default per the usual ./configure testing mrhines
2013-04-10 22:28 ` [Qemu-devel] [RFC PATCH RDMA support v1: 04/13] update QEMUFileOps with new hooks mrhines
2013-04-10 22:28 ` [Qemu-devel] [RFC PATCH RDMA support v1: 05/13] accessor function prototypes for new QEMUFileOps hooks mrhines
2013-04-10 22:28 ` [Qemu-devel] [RFC PATCH RDMA support v1: 06/13] implementation of " mrhines
2013-04-10 22:28 ` [Qemu-devel] [RFC PATCH RDMA support v1: 07/13] introduce capability for dynamic chunk registration mrhines
2013-04-11  2:24   ` Eric Blake
2013-04-11  2:39     ` Michael R. Hines
2013-04-10 22:28 ` [Qemu-devel] [RFC PATCH RDMA support v1: 08/13] default chunk registration to true mrhines
2013-04-10 22:28 ` [Qemu-devel] [RFC PATCH RDMA support v1: 09/13] parse QMP string for new 'rdma' protocol mrhines
2013-04-10 22:28 ` [Qemu-devel] [RFC PATCH RDMA support v1: 10/13] introduce new command migrate_check_for_zero mrhines
2013-04-11  2:26   ` Eric Blake
2013-04-11  2:39     ` Michael R. Hines
2013-04-11  7:52       ` Orit Wasserman
2013-04-11 12:30         ` Eric Blake
2013-04-11 12:36           ` Orit Wasserman
2013-04-11 17:53             ` Michael R. Hines
2013-04-11  3:11     ` Michael R. Hines
2013-04-11  7:38   ` Michael S. Tsirkin
2013-04-11  9:18     ` Paolo Bonzini
2013-04-11 11:13       ` Michael S. Tsirkin
2013-04-11 13:19         ` Michael R. Hines
2013-04-11 13:51           ` Michael S. Tsirkin
2013-04-11 14:06             ` Michael R. Hines
2013-04-11 14:17               ` Paolo Bonzini
2013-04-11 14:35                 ` Michael R. Hines
2013-04-11 14:45                   ` Paolo Bonzini
2013-04-11 15:37                     ` Michael R. Hines
2013-04-11 13:24       ` Michael R. Hines
2013-04-11 14:15         ` Paolo Bonzini
2013-04-11 14:45           ` Michael S. Tsirkin [this message]
2013-04-11 14:57           ` Michael R. Hines
2013-04-11 15:01             ` Michael S. Tsirkin
2013-04-11 15:08             ` Paolo Bonzini
2013-04-11 15:35               ` Michael R. Hines
2013-04-11 15:45                 ` Paolo Bonzini
2013-04-11 16:02                   ` Michael R. Hines
2013-04-11 16:12                     ` Paolo Bonzini
2013-04-11 16:07                   ` Eric Blake
2013-04-11 16:29                     ` Michael R. Hines
2013-04-11 16:36                       ` Eric Blake
2013-04-10 22:28 ` [Qemu-devel] [RFC PATCH RDMA support v1: 11/13] send pc.ram over RDMA mrhines
2013-04-11  6:26   ` Paolo Bonzini
2013-04-11 12:41     ` Michael R. Hines
2013-04-10 22:28 ` [Qemu-devel] [RFC PATCH RDMA support v1: 12/13] updated protocol documentation mrhines
2013-04-11  2:43   ` Eric Blake
2013-04-11  2:47     ` Michael R. Hines
2013-04-11  6:29   ` Paolo Bonzini
2013-04-10 22:28 ` [Qemu-devel] [RFC PATCH RDMA support v1: 13/13] print out migration throughput while debugging mrhines
2013-04-10 22:32 ` [Qemu-devel] [RFC PATCH RDMA support v7: 00/13] rdma cleanup and reordering Michael R. Hines

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=20130411144534.GE24942@redhat.com \
    --to=mst@redhat.com \
    --cc=abali@us.ibm.com \
    --cc=aliguori@us.ibm.com \
    --cc=gokul@us.ibm.com \
    --cc=mrhines@linux.vnet.ibm.com \
    --cc=mrhines@us.ibm.com \
    --cc=owasserm@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=qemu-devel@nongnu.org \
    /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).