qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PULL v4 07/11] rdma: introduce capability for chunk re


From: Michael R. Hines
Subject: Re: [Qemu-devel] [PULL v4 07/11] rdma: introduce capability for chunk registration
Date: Sun, 21 Apr 2013 13:19:17 -0400
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2

On 04/21/2013 10:17 AM, Michael S. Tsirkin wrote:
On Sun, Apr 21, 2013 at 03:19:21PM +0200, Paolo Bonzini wrote:
Il 20/04/2013 19:02, Michael S. Tsirkin ha scritto:
I guess the opposite sense could be named 'x-rdma-pin-all'; default
false means to do chunk registration and release,
chunk release only happens after migration is complete unfortunately.
This means that eventually all initialized memory is pinned, regardless
of the setting (this is fixable but there's no plan to fix this, at this
point). So pin-all might be misleading to some.

I agree 'chunk' is unnecessarily low level though.
The only difference ATM is pinning of uninitialized memory so I think a
better name would be 'x-rdma-pin-uninitialized' or some such.

x-rdma-pin-all is a better choice.  x-rdma-pin-uninitialized is also too
low level.

Since this series is likely to miss 1.5 at this point, we could
implement the unregistration part of the protocol in the destination.
This way, any heuristic we add to the source will not break backwards
compatibility.

Paolo
To test, you'll have to implement it in the source too.
That's probably a good idea anyway, though doing this
efficiently might need more thought, and some of
the tricks I described earlier (pipelining,
registration cache) might be needed.
Though I'm curious what the performance impact would be
even without these tricks.


We already had a agreement to merge with ulimit -l + ibv_reg_mr() + ERROR + abort migration.

We (IBM Research) will not commit to implementing this unless someone
provides hard data showing it not to adversely effect migration performance.

- Michael




reply via email to

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