qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Michael R. Hines" <mrhines@linux.vnet.ibm.com>
To: Paolo Bonzini <pbonzini@redhat.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 12:02:51 -0400	[thread overview]
Message-ID: <5166DEAB.5070309@linux.vnet.ibm.com> (raw)
In-Reply-To: <5166DAA0.1010507@redhat.com>

Alright, so here's a slightly different management decision
which tries to accomplish all the requests,
tell me if you like it:

1. QEMU starts up
2. *if and only if* chunk registration is disabled
     and *if and only* RDMA is enabled
             then, is_dup_page() is skipped
     Otherwise,
             everything is same as before, no change in code path
             and no zero page capability needs to be exposed to management

In this case there would be *no* capability for zero pages,
but we would still be able to detect the motivation of the
user indirectly through the chunk registration capability
by implying that since the capability was disabled then the
user is trying to optimize metrics for total migration time.

On the other hand, if the chunk registration capability is
enabled, then there is no change in the code path we because
zero page checking is mandatory to take of chunk registration
in the first place.

How does that sound? No zero page capability, but allow for
disabling only if chunk registration is disabled?

- Michael



On 04/11/2013 11:45 AM, Paolo Bonzini wrote:
> Il 11/04/2013 17:35, Michael R. Hines ha scritto:
>> Nevertheless, the initial "burst" of the bulk phase round is still
>> important to optimize, and I would like to know if the maintainer
>> would accept this API for disabling the scan or not
> I'm not a maintainer, but every opinion counts... and my opinion is "not
> yet".  Maybe for 1.6, and only after someone else tried it out.  That's
> why it's important to merge the code early.
>
>> We think it's important because the total migration time can be much
>> smaller with high-throughput RDMA links by optimizing the bulk-phase
>> round and that lower total migration time is very valuable to many of
>> our workloads, in addition to the low-downtime benefits you get with
>> RDMA.
>>
>> I have expensive numbers only for the bulk phase round. Other than that,
>> I would be breaking confidentiality outside of the paper we have already
>> published.
> Fair enough.
>
> Paolo
>

  reply	other threads:[~2013-04-11 16:06 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
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 [this message]
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=5166DEAB.5070309@linux.vnet.ibm.com \
    --to=mrhines@linux.vnet.ibm.com \
    --cc=abali@us.ibm.com \
    --cc=aliguori@us.ibm.com \
    --cc=gokul@us.ibm.com \
    --cc=mrhines@us.ibm.com \
    --cc=mst@redhat.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).