On 06/15/2011 05:20 PM, Anthony Liguori wrote:
On 06/15/2011 05:07 PM, Alexander Graf wrote:
On 16.06.2011, at 00:04, Anthony Liguori wrote:
On 06/15/2011 03:13 PM, Prasad Joshi wrote:
On Wed, Jun 15, 2011 at 6:10 PM, Pekka Enberg<penberg@xxxxxxxxxx>
wrote:
On Wed, Jun 15, 2011 at 7:30 PM, Avi Kivity<avi@xxxxxxxxxx> wrote:
On 06/15/2011 06:53 PM, Pekka Enberg wrote:
- Fast QCOW2 image read-write support beating Qemu in fio
benchmarks. See
the
following URL for test result details:
https://gist.github.com/1026888
This is surprising. How is qemu invoked?
Prasad will have the details. Please note that the above are with Qemu
defaults which doesn't use virtio. The results with virtio are little
better but still in favor of tools/kvm.
The qcow2 image used for testing was copied on to /dev/shm to avoid
the disk delays in performance measurement.
QEMU was invoked with following parameters
$ qemu-system-x86_64 -hda<disk image on hard disk> -hdb
/dev/shm/test.qcow2 -m 1024M
Looking more closely at native KVM tools, you would need to use the
following invocation to have an apples-to-apples comparison:
qemu-system-x86_64 -drive
file=/dev/shm/test.qcow2,cache=writeback,if=virtio
Wouldn't this still be using threaded AIO mode? I thought KVM tools
used native AIO?
Nope. The relevant code is:
/* blk device ?*/
disk = blkdev__probe(filename, &st);
if (disk)
return disk;
fd = open(filename, readonly ? O_RDONLY : O_RDWR);
if (fd < 0)
return NULL;
/* qcow image ?*/
disk = qcow_probe(fd, readonly);
if (disk)
return disk;
/* raw image ?*/
disk = raw_image__probe(fd, &st, readonly);
if (disk)
return disk;
It uses a synchronous I/O model similar to qcow2 in QEMU with what I
assume is a global lock that's outside of the actual implementation.
I think it lacks some of the caching that Kevin's added recently though
so I assume that if QEMU was run with cache=writeback, it would probably
do quite a bit better than native KVM tool.
It also turns out that while they have the infrastructure to deal with
FLUSH, they don't implement it for qcow2 :-/
So even if the guest does an fsync(), it native KVM tool will never
actually sync the data to disk...
That's probably why it's fast, it doesn't preserve data integrity :(
Actually, I misread the code. It does unstable writes but it does do
fsync() on FLUSH.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
