From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:54685) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qy8Nc-00085L-Po for qemu-devel@nongnu.org; Mon, 29 Aug 2011 16:24:25 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qy8Nb-0001Gj-JI for qemu-devel@nongnu.org; Mon, 29 Aug 2011 16:24:24 -0400 Received: from mail-gx0-f173.google.com ([209.85.161.173]:36068) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qy8Nb-0001GH-Fq for qemu-devel@nongnu.org; Mon, 29 Aug 2011 16:24:23 -0400 Received: by gxk26 with SMTP id 26so5821855gxk.4 for ; Mon, 29 Aug 2011 13:24:22 -0700 (PDT) Message-ID: <4E5BF571.9020607@codemonkey.ws> Date: Mon, 29 Aug 2011 15:24:17 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <1314019498-8550-1-git-send-email-aliguori@us.ibm.com> <4E525B32.2010602@siemens.com> <4E5BD461.8040500@us.ibm.com> <850D6063-D602-4CB2-8834-BE6023D13F0E@web.de> In-Reply-To: <850D6063-D602-4CB2-8834-BE6023D13F0E@web.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH] main: force enabling of I/O thread List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: =?ISO-8859-1?Q?Andreas_F=E4rber?= Cc: Peter Maydell , Alexandre Raymond , Jan Kiszka , qemu-devel Developers , Blue Swirl , Paolo Bonzini , Alexander Graf , Aurelien Jarno On 08/29/2011 03:21 PM, Andreas Färber wrote: > Am 29.08.2011 um 20:03 schrieb Anthony Liguori: > >> On 08/22/2011 08:35 AM, Jan Kiszka wrote: >>> On 2011-08-22 15:24, Anthony Liguori wrote: >>>> Enabling the I/O thread by default seems like an important part of >>>> declaring >>>> 1.0. Besides allowing true SMP support with KVM, the I/O thread >>>> means that the >>>> TCG VCPU doesn't have to multiplex itself with the I/O dispatch >>>> routines which >>>> currently requires a (racey) signal based alarm system. >>>> >>>> I know there have been concerns about performance. I think so far >>>> the ones that >>>> have come up (virtio-net) are most likely due to secondary reasons like >>>> decreased batching. >>> >>> iothread enabled without [1] gives unacceptable performance for ARM >>> emulation (Musicpal board) here. With that series applied, the host CPU >>> load is measurably higher, but no longer excessively. >> >> Given that [1] has been applied now, is there any objections to this >> patch? > > There had been additional patches to fix I/O thread issues on Darwin, > have any such fixes been applied the last few weeks? I don't see any outstanding Darwin patches in my queue so either they were applied or there were issues with them. Regards, Anthony Liguori > > The patches that I tested some time ago only fixed the non-iothread case > reliably. > > Andreas >