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

[Michael R. Hines]

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