[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Slowdowns comparing qemu-kvm.git to qemu.git: vcpu/thread s
[Qemu-devel] Slowdowns comparing qemu-kvm.git to qemu.git: vcpu/thread scheduling differences
Mon, 8 Feb 2010 19:16:45 +0530
In my testing of virtio-console, I found qemu-kvm.git introduces a lot
of overhead in thread scheduling compared to qemu.git.
My test sends a 260M file from the host to a guest via a virtio-console
port and then computes the sha1sum of the file on the host as well as on
the guest, compares the checksum and declares the result based on the
checksum match. The test passes in all the scenarios listed below,
indicating there's no unsafe data transfer.
Repo Time taken
qemu.git < 1 m (typically 30s)
qemu-kvm.git > 16m
qemu-iothread ~ 5m
The guest remains the same in all cases.
I went back upto Oct 2009 in the git history to check if this was a
regression; it is not. The qemu-kvm.git results are reproducible on
qemu-kvm-0.12.git as well.
The slowdown with qemu-iothread was reproduced by virtio-net as well:
netperf results were better on qemu.git with iothread disabled than on
qemu.git with iothread enabled.
The virtio-console code currently puts only one buffer in the in_vq,
meaning the host can only transfer 4k at a time before a guest consumes
the data and makes the buffer available for subsequent transfers.
Increasing the number of buffers available to 128 though "fixes" this --
qemu-kvm.git performance is much better in this case.
I have some gprof results comparing qemu.git and qemu-kvm.git (30% of
time in qemu-kvm.git is spent in main_loop_wait()), which I'm still
analyzing and also going over the code paths that are different.
I just thought I'd put out the observations out here so that others who
have an idea can chime in or validate these results with other
- [Qemu-devel] Slowdowns comparing qemu-kvm.git to qemu.git: vcpu/thread scheduling differences,
Amit Shah <=