All of lore.kernel.org
 help / color / mirror / Atom feed
From: Pekka Enberg <penberg@kernel.org>
To: Ingo Molnar <mingo@elte.hu>
Cc: 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: Sun, 10 Jul 2011 21:38:01 +0300	[thread overview]
Message-ID: <CAOJsxLHAJAj_4F3T3zK7r0Oz0PB+01KJp3i8ae=6tRopnzJYOg@mail.gmail.com> (raw)
In-Reply-To: <20110710181755.GB21375@elte.hu>

On Sun, Jul 10, 2011 at 9:17 PM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * Pekka Enberg <penberg@kernel.org> wrote:
>
>> Hi Ingo,
>>
>> * Pekka Enberg <penberg@kernel.org> wrote:
>> >> This series fixes QCOW locking issues and implements delayed metadata writeout.
>> >> This improves performance of writeout to QCOW2 images that don't have clusters
>> >> and L2 tables allocated on-disk.
>> >>
>> >> I tested the series by running
>> >>
>> >>   mount -t ext4 /dev/vdb /mnt
>> >>   dd if=/dev/zero of=/mnt/tmp
>> >>
>> >> in the guest multiple times for fresly generated QCOW2 image:
>> >>
>> >>   dd if=/dev/zero of=fs.ext4 bs=1024k count=512 && mkfs.ext4 -F fs.ext4 && qemu-img convert -O qcow2 fs.ext4 fs.qcow2
>> >>
>> >> which causes worst-case behavior for the current code.
>> >>
>> >> Before:
>> >>
>> >>   [ seekwatcher: http://userweb.kernel.org/~penberg/kvm-qcow-delayed/kvm-qcow2-master.png ]
>> >>
>> >>   511229952 bytes (511 MB) copied, 19.906 s, 25.7 MB/s
>> >>   511229952 bytes (511 MB) copied, 20.3168 s, 25.2 MB/s
>> >>   511229952 bytes (511 MB) copied, 20.8078 s, 24.6 MB/s
>> >>   511229952 bytes (511 MB) copied, 21.0889 s, 24.2 MB/s
>> >>   511229952 bytes (511 MB) copied, 20.7833 s, 24.6 MB/s
>> >>   511229952 bytes (511 MB) copied, 20.7536 s, 24.6 MB/s
>> >>   511229952 bytes (511 MB) copied, 20.0312 s, 25.5 MB/s
>> >>
>> >> After:
>> >>
>> >>   [ seekwatcher: http://userweb.kernel.org/~penberg/kvm-qcow-delayed/kvm-qcow2-delayed.png ]
>> >>
>> >>   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
>>
>> On Sun, Jul 10, 2011 at 8:15 PM, Ingo Molnar <mingo@elte.hu> wrote:
>> > Just wondering, how does Qemu perform on the same system using the
>> > same image, with comparable settings?
>>
>> Freshly built from qemu-kvm.git:
>>
>> $ /home/penberg/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 --version
>> QEMU emulator version 0.14.50 (qemu-kvm-devel), Copyright (c)
>> 2003-2008 Fabrice Bellard
>>
>> Tests were run with this configuration:
>>
>> $ /home/penberg/qemu-kvm/x86_64-softmmu/qemu-system-x86_64 -kernel
>> /boot/vmlinuz-3.0.0-rc5+ -drive
>> file=/home/penberg/images/debian_squeeze_amd64_standard.img,if=virtio,boot=on
>> -drive file=fs.qcow2,if=virtio -nographic -m 320 -smp 2 -append
>> "root=/dev/vda1 console=ttyS0 init=/root/iobench-write"
>>
>> Not sure if that's 100% comparable settings but anyway. The results
>> looks as follows:
>>
>>   511229952 bytes (511 MB) copied, 12.5543 s, 40.7 MB/s
>>   511229952 bytes (511 MB) copied, 9.50382 s, 53.8 MB/s
>>   511229952 bytes (511 MB) copied, 12.1092 s, 42.2 MB/s
>>   511229952 bytes (511 MB) copied, 13.2981 s, 38.4 MB/s
>>   511229952 bytes (511 MB) copied, 11.3314 s, 45.1 MB/s
>>   511229952 bytes (511 MB) copied, 12.7505 s, 40.1 MB/s
>>   511229952 bytes (511 MB) copied, 11.2921 s, 45.3 MB/s
>>
>> This is what I'd expect as tools/kvm has much more relaxed sync()
>> guarantees than qemu-kvm. We treat all writes to QCOW2 images as
>> volatile until VIRTIO_BLK_T_FLUSH is issued. Furthemore, for this
>> particular (special case) load, it's pretty much append-only to the
>> backing file which is why QCOW is so close to raw image performance
>> here.
>
> Pretty impressive numbers!
>
> To relax Qemu's caching guarantees you can append ,cache=writeback to
> your -drive option, i.e. something like:
>
>  -drive file=/dev/shm/test.qcow2,cache=writeback,if=virtio
>
> Does that improve the Qemu results?

Yes, it seems so:

  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

The numbers seem much more unstable from run to run with 'writeback'
so it's pretty difficult to say how much it helps. I'm doing
'drop_caches' after image creation so I don't quite understand why
they are so unstable.

                                Pekka

  reply	other threads:[~2011-07-10 18:38 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 [this message]
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

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='CAOJsxLHAJAj_4F3T3zK7r0Oz0PB+01KJp3i8ae=6tRopnzJYOg@mail.gmail.com' \
    --to=penberg@kernel.org \
    --cc=asias.hejun@gmail.com \
    --cc=gorcunov@gmail.com \
    --cc=kvm@vger.kernel.org \
    --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.