From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44537 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PzqV2-0003NW-Vr for qemu-devel@nongnu.org; Wed, 16 Mar 2011 09:10:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PzqV1-0005Vt-L8 for qemu-devel@nongnu.org; Wed, 16 Mar 2011 09:10:52 -0400 Received: from e37.co.us.ibm.com ([32.97.110.158]:33997) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PzqV1-0005VZ-Fm for qemu-devel@nongnu.org; Wed, 16 Mar 2011 09:10:51 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e37.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p2GD8Btc019848 for ; Wed, 16 Mar 2011 07:08:11 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p2GDAhlE120468 for ; Wed, 16 Mar 2011 07:10:47 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p2GDAhxb015512 for ; Wed, 16 Mar 2011 07:10:43 -0600 Message-ID: <4D80B6D1.4020201@us.ibm.com> Date: Wed, 16 Mar 2011 08:10:41 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20110315103453.GA23922@linux.vnet.ibm.com> <20110315103803.GC23922@linux.vnet.ibm.com> <4D7F65EF.8080906@us.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [v1 PATCH 2/3]: Helper routines to use GLib threadpool infrastructure in 9pfs. List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: arun@linux.vnet.ibm.com, jvrao@linux.vnet.ibm.com, qemu-devel@nongnu.org, aneesh.kumar@linux.vnet.ibm.com On 03/16/2011 04:20 AM, Stefan Hajnoczi wrote: > On Tue, Mar 15, 2011 at 1:13 PM, Anthony Liguori wrote: >> Why even bothering signaling for completion with the virtio-9p threadpool? >> >> There's no sane guest that's going to poll on virtio-9p completion with >> interrupts disabled and no timer. Once we enable the I/O thread by default, >> it won't even be necessary for the paio layer. > It's not just about preventing livelock under extreme cases. If you > omit the signal then !CONFIG_IOTHREAD builds will see increased > latency because virtfs request completion will piggy-back on other > events that *do* interrupt the vcpu. But realistically, the timer is firing at a high enough frequency that I doubt you'd even observe the latency. There's an easy solution here, just do some sniff testing to see if you can tell the difference. I bet you can't. > I'm no fan of !CONFIG_IOTHREAD > but skipping signals is currently bad practice and will continue to be > until CONFIG_IOTHREAD is removed entirely. > > The proper solution would be a thin abstraction for thread-safe > notification that compiles out signals when CONFIG_IOTHREAD is used. > Then we have one place in QEMU that does signalling correctly and we > can optimize it or remove CONFIG_IOTHREAD completely without having > the burden of duplicating this code in several places. We have probably 5 different ways to wake up a CPU. I don't think we should add a new one just for this. !CONFIG_IOTHREAD needs to go away in the very near future. I'd rather focus on that. Regards, Anthony Liguori > Stefan