[Qemu-devel] Re: [PATCH 2/3 v5] Block live migration

[Jan Kiszka <jan.kiszka@siemens.com>]

Liran Schour wrote:
> Jan Kiszka <jan.kiszka@siemens.com> wrote on 26/11/2009 15:53:49:
> 
> 
>>> +            qemu_get_buffer(f, buf,
>>> +                            BLOCK_SIZE);
>>> +            if(bs != NULL) {
>>> +
>>> +                bdrv_write(bs, (addr >> SECTOR_BITS),
>>> +                           buf, block_mig_state->sectors_per_block);
>> This synchronous write-back translates appears to be the reason for an
>> unusable migration (or restore from snapshot) speed: about 100 KB/s here
>> (ie. 22h for a rather small 8G guest :( ). Did you already try to
>> improve this situation?
> 
> I have seen this behavior, but it seems that there is a very big difference
> in the performance if the new block device is based on an allocated file
> already (try the same migration to an already allocated file in the
> requested size) I am trying to figure out why we see this behavior.(any
> ideas?)

Yes, much faster, more than 6 MB/s. Not really impressing, but that's
now likely due to the tiny block size.

That 4K also made the unallocated write so awfully slow as the image
file had to be continuously extended by this amount.

> Anyway we can turn the writes to be async but we have to synchronize all
> destinations writes before completing the migration and moving the guest to
> the destination. When the guest starts to run on the destination all writes
> should be finished, so anyhow we need to wait synchronously to the writes.
> I will look on this further next week.

Well, we actually need these changes:
 1. Reasonable block size (if we cannot overcome the cluster size, we
    need to coalesce blocks on write out)
 2. Async write, throttled by the sync read, or both asynchronously.
    Unfortunately, qemu's aio does not work yet at the point we need
    it...

I will also continue to dig into this.

Jan

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux