[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-discuss] savevm too slow
From: |
Kevin Wolf |
Subject: |
Re: [Qemu-discuss] savevm too slow |
Date: |
Fri, 6 Sep 2013 12:38:37 +0200 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
Am 06.09.2013 um 03:31 hat xuanmao_001 geschrieben:
> Hi, qemuers:
>
> I found that the guest disk file cache mode will affect to the time of savevm.
>
> the cache 'writeback' too slow. but the cache 'unsafe' is as fast as it can,
> less than 10 seconds.
>
> here is the example I use virsh:
> @cache with writeback:
> #the first snapshot
> real 0m21.904s
> user 0m0.006s
> sys 0m0.008s
>
> #the secondary snapshot
> real 2m11.624s
> user 0m0.013s
> sys 0m0.008s
>
> @cache with unsafe:
> #the first snapshot
> real 0m0.730s
> user 0m0.006s
> sys 0m0.005s
>
> #the secondary snapshot
> real 0m1.296s
> user 0m0.002s
> sys 0m0.008s
I sent patches that should eliminate the difference between the first
and second snapshot at least.
> so, what the difference between them when using different cache.
cache=unsafe ignores any flush requests. It's possible that there is
potential for optimisation with cache=writeback, i.e. it sends flush
requests that aren't necessary in fact. This is something that I haven't
checked yet.
> the other question: when I change the buffer size #define IO_BUF_SIZE 32768
> to #define IO_BUF_SIZE (1 * 1024 * 1024), the savevm is more quickly.
Is this for cache=unsafe as well?
Juan, any specific reason for using 32k? I think it would be better to
have a multiple of the qcow2 cluster size, otherwise we get COW for the
empty part of newly allocated clusters. If we can't make it dynamic,
using at least fixed 64k to match the qcow2 default would probably
improve things a bit.
Kevin