From: Kevin Wolf <kwolf@redhat.com>
To: xuanmao_001 <xuanmao_001@163.com>
Cc: mreitz@redhat.com, quintela@redhat.com,
qemu-devel <qemu-devel@nongnu.org>,
stefanha@redhat.com, qemu-discuss <qemu-discuss@nongnu.org>
Subject: Re: [Qemu-devel] savevm too slow
Date: Fri, 6 Sep 2013 12:38:37 +0200 [thread overview]
Message-ID: <20130906103837.GH2588@dhcp-200-207.str.redhat.com> (raw)
In-Reply-To: <2013090609312026502832@163.com>
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
next prev parent reply other threads:[~2013-09-06 10:39 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-09-06 1:31 [Qemu-devel] savevm too slow xuanmao_001
2013-09-06 10:38 ` Kevin Wolf [this message]
2013-09-09 1:57 ` xuanmao_001
2013-09-09 8:35 ` Kevin Wolf
2013-09-09 8:47 ` xuanmao_001
2013-09-09 9:16 ` Kevin Wolf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130906103837.GH2588@dhcp-200-207.str.redhat.com \
--to=kwolf@redhat.com \
--cc=mreitz@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=qemu-discuss@nongnu.org \
--cc=quintela@redhat.com \
--cc=stefanha@redhat.com \
--cc=xuanmao_001@163.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).