From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LkqLi-0008Rk-FV for qemu-devel@nongnu.org; Fri, 20 Mar 2009 21:50:10 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LkqLd-0008QC-C5 for qemu-devel@nongnu.org; Fri, 20 Mar 2009 21:50:09 -0400 Received: from [199.232.76.173] (port=33056 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LkqLd-0008Q6-5m for qemu-devel@nongnu.org; Fri, 20 Mar 2009 21:50:05 -0400 Received: from an-out-0708.google.com ([209.85.132.248]:63562) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LkqLc-0004pM-QF for qemu-devel@nongnu.org; Fri, 20 Mar 2009 21:50:04 -0400 Received: by an-out-0708.google.com with SMTP id c5so836696anc.37 for ; Fri, 20 Mar 2009 18:50:04 -0700 (PDT) Message-ID: <49C447C9.9050405@codemonkey.ws> Date: Fri, 20 Mar 2009 20:50:01 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20090319145705.988576615@localhost.localdomain> <20090319150537.910101569@localhost.localdomain> <49C3D5D5.4020006@codemonkey.ws> <20090321000617.GA26654@amt.cnet> <49C43D29.7000206@codemonkey.ws> <20090321014452.GB27020@amt.cnet> In-Reply-To: <20090321014452.GB27020@amt.cnet> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [patch 2/7] qemu: separate thread for io Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcelo Tosatti Cc: qemu-devel@nongnu.org, Avi Kivity 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