Re: [PATCH 0/9] kvm tools, qcow: Improve QCOW performance

[Kevin Wolf <kwolf@redhat.com>]

Am 10.07.2011 20:08, schrieb Pekka Enberg:
> 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:

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.

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.

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.

Kevin