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

[Michael S. Tsirkin]

On Sun, Apr 21, 2013 at 01:19:17PM -0400, Michael R. Hines wrote:
> 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.

Not sure who is 'we' here, but for the record, I did not agree to merge
these patches, and I'm the wrong person to ask to merge them.
Juan is probably the right person to ask about merging them.

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


-- 
MST