Re: [Qemu-devel] [PATCH] ram_save_live: add a no-progress convergence rule

[Uri Lublin <uril@redhat.com>]

On 05/19/2009 09:09 PM, Anthony Liguori wrote:
> Glauber Costa wrote:
>> Another possibility is for the management tool to increase the
>> bandwidth for
>> little periods if it perceives that no progress is being made.
>>
>> Anyhow, I completely agree that we should not introduce this in qemu.
>>
>> However, maybe we could augment our "info migrate" to provide more
>> info about
>> the internal state of migration, so the mgmt tool can take a more
>> informed
>> decision?
> Yes, I've also suggested this before. I'm willing to expose just about
> any metric that makes sense. We need to be careful about not exposing
> implementation details, but things like iteration count, last working
> set size, average working set size, etc. should all be relatively stable
> metrics even if the implementation changes.
>

I agree we need to provide more information via "info migration". That's not 
enough though.

In addition of augmenting "info migration" we need to add more monitor commands 
to set/change migration parameters (e.g. current bandwidth limit), and change 
the migration code to act according to such parameters. These commands should 
affect the migration when used before and during migration.

Note that as management tool, most likely, call "info migration" periodically, 
it may miss information about some (current/last) statistics.
Also the first iteration may cause some averages to get biased.

How would you recognize "stuck" migrations ? By comparing Average Working Set 
Size and Average Iteration Transfer Size ? Counting the number of no-progress 
iterations ? The average "regression" of no-progress iterations ?

The no-progress convergence rule was fairly easy to implement and gave a pretty 
good heuristic to recognizing the migration is stuck.

Regards,
     Uri.