All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pekka Enberg <penberg@kernel.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: Kevin Wolf <kwolf@redhat.com>,
	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 13:44:56 +0300	[thread overview]
Message-ID: <CAOJsxLGEe5HK7WjLAtx5j1vb8AB0P4UL4_Cg8LGo2J11wuqJOg@mail.gmail.com> (raw)
In-Reply-To: <20110711103645.GA11338@elte.hu>

On Mon, Jul 11, 2011 at 1:36 PM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Pekka Enberg <penberg@kernel.org> wrote:
>
>> > 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.
>
> tools/kvm/ seems to be about 20% faster on average:
>
>   511229952 bytes (511 MB) copied, 7.68312 s, 66.5 MB/s
>   511229952 bytes (511 MB) copied, 7.54065 s, 67.8 MB/s
>   511229952 bytes (511 MB) copied, 9.34749 s, 54.7 MB/s
>   511229952 bytes (511 MB) copied, 9.2421 s, 55.3 MB/s
>   511229952 bytes (511 MB) copied, 9.9364 s, 51.5 MB/s
>   511229952 bytes (511 MB) copied, 10.0337 s, 51.0 MB/s
>   511229952 bytes (511 MB) copied, 9.39502 s, 54.4 MB/s
>
> versus the qemu numbers:
>
>  511229952 bytes (511 MB) copied, 10.0879 s, 50.7 MB/s
>  511229952 bytes (511 MB) copied, 4.92686 s, 104 MB/s
>  511229952 bytes (511 MB) copied, 13.1955 s, 38.7 MB/s
>  511229952 bytes (511 MB) copied, 10.7322 s, 47.6 MB/s
>  511229952 bytes (511 MB) copied, 9.46115 s, 54.0 MB/s
>  511229952 bytes (511 MB) copied, 14.9963 s, 34.1 MB/s
>  511229952 bytes (511 MB) copied, 11.1701 s, 45.8 MB/s
>
> but indeed there's (much) more variability in the Qemu numbers,
> suggesting some cache artifact.
>
> Are all of these measurements done via /dev/shm, to stabilize the
> numbers and to remove disk IO delay artifacts?

No, I wanted to include disk IO delay artifacts because I was
comparing tools/kvm to itself using seekwatcher to see what's really
happening. And as Kevin pointed out, we're still missing refcount
tables from tools/kvm so it's not a proper comparison anyway. It does
show that tools/kvm QCOW performance improved significantly, though.

                                Pekka

      reply	other threads:[~2011-07-11 10:44 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
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 [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=CAOJsxLGEe5HK7WjLAtx5j1vb8AB0P4UL4_Cg8LGo2J11wuqJOg@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.