|
From: | Anthony Liguori |
Subject: | [Qemu-devel] Re: [patch 2/7] qemu: separate thread for io |
Date: | Fri, 20 Mar 2009 20:50:01 -0500 |
User-agent: | Thunderbird 2.0.0.19 (X11/20090105) |
Marcelo Tosatti wrote:
There was a significant (25% IIRC) reduction in iperf performance. This is sort of expected, since there are no optimizations at all (should collapse the signals sent to TCG context, for one). But my thinking is to merge the iothread (along the lines of this patchset), stabilize and then optimize. How about that?
I don't mind that but I'll need to check out how things behave with TCG and with other guest architectures. I'm willing to accept a temporary performance regression in something like iperf because I don't think people are relying on QEMU network performance that much today (outside of KVM/Xen) but if we have significant performance regressions with non-x86 boards with things like basic boot time, we'll have to fix those first.
We also need to not completely break the Windows build before merging.
Have you thought about how this is going to affect kvm-userspace?Oops, no. But I can be held accountable for kvm-userspace iothread until it can be fully replaced by upstream.
Before merging into QEMU, we should at least make sure that it's not going to create a nightmare for Avi :-)
Do you think we can eliminate the io threading code in kvm-userspace after this goes in?Not immediately, need to generalize some of the changes introduced by the patchset and merge the remaining logic of kvm-userspace's qemu-kvm.c.
Yeah, I thought it would take some work. Great work Marcelo! Regards, Anthony Liguori
[Prev in Thread] | Current Thread | [Next in Thread] |