From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=54084 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pmne4-0004AD-1B for qemu-devel@nongnu.org; Tue, 08 Feb 2011 08:30:17 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pmne1-00083G-Rv for qemu-devel@nongnu.org; Tue, 08 Feb 2011 08:30:15 -0500 Received: from hall.aurel32.net ([88.191.126.93]:58592) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pmne1-00082l-Eu for qemu-devel@nongnu.org; Tue, 08 Feb 2011 08:30:13 -0500 Message-ID: <4D514558.9010003@aurel32.net> Date: Tue, 08 Feb 2011 14:30:00 +0100 From: Aurelien Jarno MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 2/7] Enable I/O thread and VNC threads by default References: <4D3DFD20.8060004@linux.vnet.ibm.com> <20110125091741.GB30239@edde.se.axis.com> <20110125133453.GC5427@amt.cnet> <20110207101255.GA20413@amt.cnet> <20110207160350.GA26332@amt.cnet> <4D501C71.7090708@redhat.com> <4D50279B.5010102@siemens.com> <4D505DCB.9050406@codemonkey.ws> <20110207214551.GB16429@hall.aurel32.net> <4D50A5F0.802@codemonkey.ws> <20110208072657.GD16429@hall.aurel32.net> <4D50FA14.5010100@redhat.com> <4D5103E8.6050808@siemens.com> <4D510771.3040309@aurel32.net> <4D511221.9030505@siemens.com> <4D5113D3.9090802@aurel32.net> <4D511500.1040303@siemens.com> <4D5115C2.6060008@aurel32.net> <4D51842C.8000209@codemonkey.ws> <4D5125E2.8090902@aurel32.net> <4D5196DE.6030009@codemonkey.ws> In-Reply-To: <4D5196DE.6030009@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Stefan Hajnoczi , Jan Kiszka , Marcelo Tosatti , "qemu-devel@nongnu.org" , Anthony Liguori , Paul Brook , "Edgar E. Iglesias" , Paolo Bonzini , Arun Bharadwaj Anthony Liguori a écrit : > On 02/08/2011 05:15 AM, Aurelien Jarno wrote: >> Anthony Liguori a écrit : >> >>> On 02/08/2011 04:06 AM, Aurelien Jarno wrote: >>> >>>> Yes, it's slow. But is it a problem? You assume that people use QEMU >>>> only for emulating SMP platforms. This is a wrong assumption. Beside the >>>> x86 target, only sparc really supports SMP emulation. >>>> >>>> >>> It's *not* just about performance. >>> >>> TCG requires a signal to break out of a tight chained TB loop. If you >>> have a guest in a tight loop waiting for something external (like >>> polling on a in-memory flag), the device emulation will not get to run >>> until a signal is fired. >>> >>> Unless you set SIGIO on every file descriptor that selects polls on (and >>> you can't because there are a number that just don't support SIGIO), >>> then you have a race condition. >>> >>> >> In practice you will get a signal when the next timer event expire. I >> agree it's suboptimal, but it works, and has been like that for here. >> > > During early boot up before the periodic timer is enabled can cause > quite a noticable issue here. > > I think it's cris specifically that does polling I/O in the early > startup before any periodic timer is enabled. > >> Having that fixed through an I/O thread is actually quite nice, however >> it should not be done ignoring all the *current* drawbacks of the >> iothread mode. We know them (at least for some of them), so let's try to >> solve them. >> > > Yes, agree 100%. > >> And now, I don't buy the argument "it's been there for years", it was >> *disabled* by default. >> > > Yeah, I think we need to enable it by default and commit to fixing all > of the outstanding issues. So the strategy is let's break everything and wait for the maintainer to fix that? This strategy doesn't work, we have seen for example that with the SeaBIOS switch. While it brings nice features, it has broken the isapc machine. And it's still not fixed... Also this strategy doesn't scale, then the maintainers are spending their time fixing bugs introduced because others didn't care. Resources are not unlimited, especially for those doing that on their free time. > I think we've fixed all that we're aware of but we probably won't find > the rest unless we enable it universally. I agree that we are going to discover bugs, and it's normal. QEMU is quite complex and it's not possible to test every combination. That said we are already aware of some bugs, why not fix them, or at least try to fix them? For example we haven't fixed the performance regression with TCG (at least it wasn't the case two weeks ago). -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurelien@aurel32.net http://www.aurel32.net