Re: [Qemu-devel] [PATCH] augment info migrate with page status

[Glauber Costa]

>
> It would be nice to zero pages_transferred each migration operation.
Yeah, that makes sense.

> ram_save_threshold is really to small. From Uri's past measurements, as  
> value of 50 is a
> better suite.
Every value is arbitrary in essence. If after this patches we still see need
to change that, I'd say change it to a percentage of guest total memory,
or even better, the average number of pages that were transferred per iteration

> Alternately it can be parametrized by the monitor command.
With this, I completely disagree. Let us say we switch in the future to a
new migration algorithm that does not rely on any treshold at all. What
should we do with this parameter?

This is totally implementation dependant, and should not be exposed.
the bandwidth is what we want to control externally.

>
> In general there is small drawback in the current approach:
> The way bandwidth is capped,  iirc,  in every second you start consuming  
> migration
> bandwidth. If the bandwidth allocation was consumed after 100msec,  
> you'll wait 900msec.
> In this period, mgmt app reading the ram_save_remaining will notice that  
> migration does
> not progress and might either increase bandwidth or stop the guest.

So what? If one second is too much, have them to use 500ms. Also, if the 
bandwidth
was consumed after 100 ms and the number of remaining pages _increased_ when 
mgmt
tool read it again, this is the most genuine case of need for increasing 
bandwidth
in the whole universe.

Or have them use a better algorithm altogether.
The point is, this is not qemu's problem.