[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: Thu, 11 Apr 2013 13:27:58 -0400
User-agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130106 Thunderbird/17.0.2

On 04/11/2013 01:04 PM, Michael S. Tsirkin wrote:
On Thu, Apr 11, 2013 at 12:09:44PM -0400, Michael R. Hines wrote:

Yes, that's correct. The agony is just delayed. The right thing to do
in a future patch would be to pin as much as possible in advance
before the bulk phase round even begins (using the pagemap).
IMHO the right thing is to unpin memory after it's sent.

Based on what, exactly? Would you unpin a hot page? Would you
unpin a cold page that becomes hot again later? I don't see how we can
know in advance the behavior of individual pages and make the decision
to unpin them - we probably don't want to know either.

Trying to build a more complex protocol just for something that's unpredictable (and probably not the common case) doesn't seem like a good focus for debate.

Overcommit is really only useful when the "overcommitted" memory
is not expected to fluctuate. Unpinning pages just so they can be overcommitted later means that it was probably a bad idea to overcommit those pages in the first place....

What you're asking for is very fine-grained overcommitment, which, in my
experience is not a practical decision making process that QEMU can ever really know
about. Memory footprints tend to either be very big or very small
and they stay that way for a very long time until something comes along to change that.

In the meantime, chunk registartion performance is still very good
so long as total migration time is not the metric you are optimizing for.
You mean it has better downtime than TCP? Or lower host CPU
overhead? These are the metrics we care about.
Yes, it does indeed have better downtime because RDMA latencies are much
lower and *most* of the page registrations will have already occurred after
the bulk phase round has passed in the first iteration.


- Michael

If you mean that registering all memory is a requirement,
then I am not sure I agree: you wrote one slow protocol, this
does not mean that there can't be a fast one.

But if you mean to say that the current chunk based code
is useless, then I'd have to agree.
Answer above.
I don't see it above. What does "keep it simple mean"?

By simple, I mean the argument for a simpler protocol that I made above.

- Michael

reply via email to

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