[Top][All Lists]

[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.


reply via email to

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