From: Paolo Bonzini <pbonzini@redhat.com>
To: "Michael R. Hines" <mrhines@linux.vnet.ibm.com>
Cc: aliguori@us.ibm.com, "Michael S. Tsirkin" <mst@redhat.com>,
qemu-devel@nongnu.org, 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 16:15:54 +0200 [thread overview]
Message-ID: <5166C59A.4010904@redhat.com> (raw)
In-Reply-To: <5166B9A9.9070904@linux.vnet.ibm.com>
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
next prev parent reply other threads:[~2013-04-11 14:23 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 [this message]
2013-04-11 14:45 ` Michael S. Tsirkin
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=5166C59A.4010904@redhat.com \
--to=pbonzini@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=mst@redhat.com \
--cc=owasserm@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).