[Qemu-devel] big wait check in ram_save_iterate()

[Qemu-devel] big wait check in ram_save_iterate()

[Peter Lieven]

Hi,

is the check for spending > 50ms in the loop still necessary in qemu 1.3.0?

Peter

Re: [Qemu-devel] big wait check in ram_save_iterate()

[Paolo Bonzini]

> is the check for spending > 50ms in the loop still necessary in qemu
> 1.3.0?

Yes, it helps finding the available bandwidth and tuning the downtime of
migration.

Paolo

Re: [Qemu-devel] big wait check in ram_save_iterate()

[Peter Lieven]

Am 15.12.2012 10:02, schrieb Paolo Bonzini:
> 
>> is the check for spending > 50ms in the loop still necessary in qemu
>> 1.3.0?
> 
> Yes, it helps finding the available bandwidth and tuning the downtime of
> migration.

Aha, okay. But then it should also be added to block migration, shoudn't it?

I tested it in qemu-kvm 1.2.0 and it help to increase responsiveness if the
I/O latency on the storage is high.

Peter

> 
> Paolo
> 

Re: [Qemu-devel] big wait check in ram_save_iterate()

[Paolo Bonzini]

Il 15/12/2012 12:20, Peter Lieven ha scritto:
> Am 15.12.2012 10:02, schrieb Paolo Bonzini:
>>
>>> is the check for spending > 50ms in the loop still necessary in qemu
>>> 1.3.0?
>>
>> Yes, it helps finding the available bandwidth and tuning the downtime of
>> migration.
> 
> Aha, okay. But then it should also be added to block migration, shoudn't it?

The main problem with block migration is that it uses the same strategy
for RAM and storage migration, but the two are very different.

In RAM migration, you are basically fighting an uphill battle.  You
cannot do RAM migration without some amount of downtime, because CPUs
are always going to be faster than the migration process and latency is
zero.

But in storage migration you have the same constraints as the guest.
Disk is slow for the guest too (and as slow as network, or slower).  The
guest needs to flush to disk, while the migration process does not need
to do that.  And migration can proceed asynchronously, just like the
guest, with multiple in-flight operations at the same time.

drive-mirror can do all this much better than migration, and without
slowing down RAM migration (which occurs on a separate socket).  See the
drive-mirror patches that I posted recently for 1.4.  With those
patches, I can sync the destination to the source every 100 ms during a
kernel compilation, and every 1-2 seconds during hibernation (the
absolute worst case) using iSCSI for both the source and the target and
a middle-range SAS disk.  This is a far cry from what RAM migration can
achieve on any reasonable workload, and it's the reason why I'm pushing
for a separate mechanism than the migrate command.

libvirt has had patches posted to support this too.

Paolo

> I tested it in qemu-kvm 1.2.0 and it help to increase responsiveness if the
> I/O latency on the storage is high.