[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC PATCH RDMA support v1: 10/13] introduce new comman

From: Michael R. Hines
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
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2

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
            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

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
Fair enough.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]