From: Luiz Capitulino <lcapitulino@redhat.com>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>, qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] block: regression: savevm/delvm too slow
Date: Wed, 22 Jun 2011 09:44:19 -0300 [thread overview]
Message-ID: <20110622094419.2ee2d06a@doriath> (raw)
In-Reply-To: <4E01AE27.1040407@redhat.com>
On Wed, 22 Jun 2011 10:56:07 +0200
Kevin Wolf <kwolf@redhat.com> wrote:
> Am 21.06.2011 19:29, schrieb Luiz Capitulino:
> > I'm getting the following times when doing a savevm and delvm in current
> > HEAD eb47d7c5d (time in minutes, each time corresponds to a savevm/delvm run):
> >
> > savevm: 5:28m, 11:00m, 11:10m
> > delvm: 4:30m, 4:40m, > 15m
> >
> > Now, trying with qemu 0.13.0 I get:
> >
> > savevm: < 1:00m, 4:00m, 4:34m
> > delvm: few seconds for all cases
> >
> > Yes, you read it correctly, I tried with 0.13.0 because 0.14.0 also has the
> > bug. This is the pattern I see when I run strace against HEAD while running
> > the savevm command:
> >
> > pwrite(7, "\0\1\0\1\0\1\0\1\0\2\0\2\0\2\0\2\0\2\0\2\0\2\0\2\0\2\0\2\0\2\0\2"..., 65536, 196608) = 65536
> > fdatasync(7) = 0
> >
> > Ie. a fdatasync() follows every single pwrite(). Something similar also happens
> > with delvm. I don't see this pattern with 0.13.0.
> >
> > The good news is that I've tracked it down and Mr. git bisect says that:
> >
> > 29c1a7301af752de6721e031d31faa48887204bd is the first bad commit
> > commit 29c1a7301af752de6721e031d31faa48887204bd
> > Author: Kevin Wolf <kwolf@redhat.com>
> > Date: Mon Jan 10 17:17:28 2011 +0100
> >
> > qcow2: Use QcowCache
> >
> > Use the new functions of qcow2-cache.c for everything that works on refcount
> > block and L2 tables.
> >
> > Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> >
> > :040000 040000 83e364185d37845bb27f1dccd1249d14cc7a9a1e 0c91964a52b5869333d4fb2cb0fa83104151359e M block
>
> Let me guess... You're using cache=writethrough?
I'm using default options. To do the tests I started qemu with:
# qemu -hda disks/test2.img -enable-kvm -m 1G -monitor stdio
>
> Previously, qcow2_update_snapshot_refcount() had implemented its own
> kind of writeback cache that would be used even with cache=writethrough.
> Now we're using the generic Qcow2Cache, which implements a write-through
> behaviour for cache=writethrough.
>
> We could fix this by temporarily switching the cache to writeback mode.
>
> Kevin
>
prev parent reply other threads:[~2011-06-22 12:44 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-21 17:29 [Qemu-devel] block: regression: savevm/delvm too slow Luiz Capitulino
2011-06-22 8:56 ` Kevin Wolf
2011-06-22 12:44 ` Luiz Capitulino [this message]
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=20110622094419.2ee2d06a@doriath \
--to=lcapitulino@redhat.com \
--cc=kwolf@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.