All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pekka Enberg <penberg@kernel.org>
To: Kevin Wolf <kwolf@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	kvm@vger.kernel.org, Asias He <asias.hejun@gmail.com>,
	Cyrill Gorcunov <gorcunov@gmail.com>,
	Prasad Joshi <prasadjoshi124@gmail.com>,
	Sasha Levin <levinsasha928@gmail.com>
Subject: Re: [PATCH 0/9] kvm tools, qcow: Improve QCOW performance
Date: Mon, 11 Jul 2011 12:41:15 +0300	[thread overview]
Message-ID: <CAOJsxLFX5sLRtVfD4hoAx6h+0Pdd8SEXa=5MgOKiGrfdk9NCdQ@mail.gmail.com> (raw)
In-Reply-To: <4E1AC2E2.8040608@redhat.com>

Hi Kevin,

On Mon, Jul 11, 2011 at 12:31 PM, Kevin Wolf <kwolf@redhat.com> wrote:
> I would love to try out your code occasionally myself, but so far I have
> been to lazy to build a guest kernel only to be able to test it. Having
> to deal with the huge kernel git tree just for a small program doesn't
> really make it more fun either... Anyway, what I'm trying to say is that
> everything in my mails is from a purely theoretical POV. I have only
> looked at the code, but never really tried it.

Most distro kernels boot just fine, AFAIK. If you have a kernel tree
laying around, you can use

  git remote add kvm-tool git://github.com/penberg/linux-kvm.git
  git remote update kvm-tool

to fetch the sources.

> As Ingo already said, the cache mode is probably the major difference.
> From what I can see in your code, cache=writeback would be the
> equivalent for what tools/kvm is doing, however cache=none (i.e.
> O_DIRECT) is what people usually do with qemu.

Yup, I posted 'cache=writeback' results too which are much closer to
tools/kvm numbers.

> And then there seems to be another big difference. I hope I'm not
> missing anything, but you seem to be completely lacking refcount
> handling for qcow2. This is okay for read-only image, but with write
> access to the image, you're corrupting the images if you don't update
> the refcounts. Have you checked qcow2 images with qemu-img check after
> tools/kvm having written to it?
>
> Maintaining the right order between L2 writes and refcount block writes
> is another source of flushes in qemu, which of course makes a difference
> for performance.

Yes, you're absolutely correct. We don't support copy-on-write images
and I didn't realize until yesterday evening that we don't even check
the 'copied' bit to make sure writes are safe.

However, for these particular numbers, it doesn't matter that much
because it's all append-only and thus shouldn't trigger any of the
copy-on-write paths.

                                Pekka

  reply	other threads:[~2011-07-11  9:41 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-07-09 13:02 [PATCH 0/9] kvm tools, qcow: Improve QCOW performance Pekka Enberg
2011-07-09 13:02 ` [PATCH 1/9] kvm tools, qcow: Rename struct qcow_l2_cache to struct qcow_l2_table Pekka Enberg
2011-07-09 13:02 ` [PATCH 2/9] kvm tools, qcow: Use 'struct qcow_l2_table' instead of untyped array Pekka Enberg
2011-07-09 13:02 ` [PATCH 3/9] kvm tools, qcow: Fix locking issues Pekka Enberg
2011-07-09 13:02 ` [PATCH 4/9] kvm tools, qcow: Introduce qcow_disk_flush() Pekka Enberg
2011-07-09 13:02 ` [PATCH 5/9] kvm tools, qcow: Delayed L1 table writeout Pekka Enberg
2011-07-09 13:02 ` [PATCH 6/9] kvm tools, qcow: Don't fdatasync() L2 " Pekka Enberg
2011-07-09 13:02 ` [PATCH 7/9] kvm tools, qcow: Use big endian order for L2 table entries Pekka Enberg
2011-07-09 13:02 ` [PATCH 8/9] kvm tools, qcow: Delayed L2 table writeout Pekka Enberg
2011-07-09 13:02 ` [PATCH 9/9] kvm tools, qcow: Flush only dirty L2 tables Pekka Enberg
2011-07-10 17:15 ` [PATCH 0/9] kvm tools, qcow: Improve QCOW performance Ingo Molnar
2011-07-10 18:08   ` Pekka Enberg
2011-07-10 18:17     ` Ingo Molnar
2011-07-10 18:38       ` Pekka Enberg
2011-07-11  9:31     ` Kevin Wolf
2011-07-11  9:41       ` Pekka Enberg [this message]
2011-07-11 10:29         ` Kevin Wolf
2011-07-11 10:32           ` Pekka Enberg
2011-07-11 10:36         ` Ingo Molnar
2011-07-11 10:44           ` Pekka Enberg

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='CAOJsxLFX5sLRtVfD4hoAx6h+0Pdd8SEXa=5MgOKiGrfdk9NCdQ@mail.gmail.com' \
    --to=penberg@kernel.org \
    --cc=asias.hejun@gmail.com \
    --cc=gorcunov@gmail.com \
    --cc=kvm@vger.kernel.org \
    --cc=kwolf@redhat.com \
    --cc=levinsasha928@gmail.com \
    --cc=mingo@elte.hu \
    --cc=prasadjoshi124@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.