[Top][All Lists]

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

Re: [Qemu-devel] [RFC PATCH RDMA support v5: 03/12] comprehensive protoc

From: Michael R. Hines
Subject: Re: [Qemu-devel] [RFC PATCH RDMA support v5: 03/12] comprehensive protocol documentation
Date: Sun, 14 Apr 2013 10:40:24 -0400
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2

On 04/14/2013 10:09 AM, Paolo Bonzini wrote:
Il 14/04/2013 13:59, Michael S. Tsirkin ha scritto:
I agree assuming guest has lots of zero pages won't work, but I think
you are overstating the importance of overcommit.  Let's mark the damn
thing as experimental, and stop making perfect the enemy of good.
It looks like we have to decide, before merging, whether migration with
rdma that breaks overcommit is worth it or not.  Since the author made
it very clear he does not intend to make it work with overcommit, ever.
To me it is very much worth it.

I would like to understand if unregistration would require a protocol
change, but that's really more a curiosity than anything else.

Yes, it would require a protocol change. Either the source or the
destination would have to arbitrarily "decide" when is the time to
perform the unregistration without adversely causing the page
to be RE-registered over and over again during future iterations.

I really don't see how QEMU can accurately make such a decision.

Perhaps it would make sense to make chunk registration permanent only
after the bulk phase.  Chunks registered in the bulk phase are not

Unfortunately, that would require the entire memory footprint
to be pinned during the bulk round, which was what Michael
was originally trying to avoid a couple of weeks ago.

Nevertheless, the observation is accurate: We already have
a capability to disable chunk registration entirely.

If the user doesn't want it, they can just turn it off.

- Michael


reply via email to

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