qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: Kevin Wolf <kwolf@redhat.com>
To: "Denis V. Lunev" <den@openvz.org>
Cc: qemu-block@nongnu.org, qemu-devel@nongnu.org,
	Pavel Borzenkov <pborzenkov@virtuozzo.com>,
	Max Reitz <mreitz@redhat.com>,
	jsnow@redhat.com
Subject: Re: [Qemu-devel] [PATCH 1/1] qcow2: avoid extra flushes in qcow2
Date: Wed, 1 Jun 2016 12:07:01 +0200	[thread overview]
Message-ID: <20160601100701.GD5356@noname.str.redhat.com> (raw)
In-Reply-To: <1464772324-7354-1-git-send-email-den@openvz.org>

Am 01.06.2016 um 11:12 hat Denis V. Lunev geschrieben:
> qcow2_cache_flush() calls bdrv_flush() unconditionally after writing
> cache entries of a particular cache. This can lead to as many as
> 2 additional fdatasyncs inside bdrv_flush.
> 
> We can simply skip all fdatasync calls inside qcow2_co_flush_to_os
> as bdrv_flush for sure will do the job.

This looked wrong at first because flushes are needed to keep the right
order of writes to the different caches. However, I see that you keep
the flush in qcow2_cache_flush_dependency(), so in the code this is
actually fine.

Can you make that more explicit in the commit message?

> This seriously affects the
> performance of database operations inside the guest.
> 
> Signed-off-by: Denis V. Lunev <den@openvz.org>
> CC: Pavel Borzenkov <pborzenkov@virtuozzo.com>
> CC: Kevin Wolf <kwolf@redhat.com>
> CC: Max Reitz <mreitz@redhat.com>

Do you have performance numbers for master and with your patch applied?
(No performance related patch should come without numbers in its commit
message!)

What I find interesting is that this seems to help even though
duplicated flushes should actually be really cheap because there is no
new data that could be flushed in the second request. Makes me wonder if
guests send duplicated flushes, too, and whether we should optimise
that.

Maybe it would also be interesting to measure how things perform if we
removed the flush from qcow2_cache_flush_dependency(). This would be
incorrect code (corruption possible after host crash), but I'd like to
know how much performance we actually lose here. This is performance
that could potentially be gained by using a journal.

Kevin

  reply	other threads:[~2016-06-01 10:07 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-01  9:12 [Qemu-devel] [PATCH 1/1] qcow2: avoid extra flushes in qcow2 Denis V. Lunev
2016-06-01 10:07 ` Kevin Wolf [this message]
2016-06-01 11:35   ` Pavel Borzenkov
2016-06-02 13:38   ` Pavel Borzenkov
  -- strict thread matches above, loose matches on Subject: below --
2016-06-02 15:58 Denis V. Lunev
2016-06-03  8:38 ` 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=20160601100701.GD5356@noname.str.redhat.com \
    --to=kwolf@redhat.com \
    --cc=den@openvz.org \
    --cc=jsnow@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=pborzenkov@virtuozzo.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /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).