qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jan Kiszka
Subject: [Qemu-devel] Re: [PATCH 2/3 v5] Block live migration
Date: Thu, 26 Nov 2009 18:05:48 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); de; rv:1.8.1.12) Gecko/20080226 SUSE/2.0.0.12-1.1 Thunderbird/2.0.0.12 Mnenhy/0.7.5.666

Liran Schour wrote:
> Jan Kiszka <address@hidden> 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




reply via email to

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