[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Qemu-devel] Re: Slowdowns comparing qemu-kvm.git to qemu.git: vcpu/thre
[Qemu-devel] Re: Slowdowns comparing qemu-kvm.git to qemu.git: vcpu/thread scheduling differences
Mon, 08 Feb 2010 14:28:42 -0600
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:18.104.22.168) Gecko/20091209 Fedora/3.0-4.fc12 Lightning/1.0pre Thunderbird/3.0
On 02/08/2010 11:35 AM, Amit Shah wrote:
On (Mon) Feb 08 2010 [08:57:05], Anthony Liguori wrote:
On 02/08/2010 07:46 AM, Amit Shah wrote:
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-iothread ~ 5m
That very likely suggests that there are missing qemu_notify_events() in
qemu-kvm.git and you're getting blocked waiting for the next timer event
Hm, if that's the case, should virtio_notify() have a call to
No, basically, the problem will boil down to, the IO thread is
select()'d waiting for an event to occur. However, you've done
something in the VCPU thread that requires the IO thread to run it's
main loop. You need to use qemu_notify_event() to force the IO thread
to break out of select().
Debugging these problems are very difficult and the complexity here is
the main reason the IO thread still hasn't been enabled by default in
I'd suggest looking at the main loop in qemu-kvm, seeing what isn't
processed as a result of fd becoming readable/writable, and then making
sure that any of those mechanisms you're relying on in virtio-console
have the appropriate tie-ins to qemu_notify_event().