qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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
> 

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