From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nkjnm-0004S8-KE for qemu-devel@nongnu.org; Thu, 25 Feb 2010 14:55:14 -0500 Received: from [199.232.76.173] (port=39266 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nkjnm-0004Rn-4z for qemu-devel@nongnu.org; Thu, 25 Feb 2010 14:55:14 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nkjnk-0003XA-A7 for qemu-devel@nongnu.org; Thu, 25 Feb 2010 14:55:13 -0500 Received: from mail-iw0-f177.google.com ([209.85.223.177]:53298) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nkjnk-0003X4-0P for qemu-devel@nongnu.org; Thu, 25 Feb 2010 14:55:12 -0500 Received: by iwn7 with SMTP id 7so5501420iwn.4 for ; Thu, 25 Feb 2010 11:55:11 -0800 (PST) Message-ID: <4B86D59C.3000300@codemonkey.ws> Date: Thu, 25 Feb 2010 13:55:08 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [RFC][PATCH] performance improvement for windows guests, running on top of virtio block device References: <1263195647.2005.44.camel@localhost> <201002240258.19045.paul@codesourcery.com> <4B853ED3.3060707@codemonkey.ws> <201002251506.05318.paul@codesourcery.com> <4B86AF40.5090401@redhat.com> <4B86B044.6020501@codemonkey.ws> <4B86B45B.5020507@redhat.com> In-Reply-To: <4B86B45B.5020507@redhat.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: Vadim Rozenfeld , Dor Laor , Christoph Hellwig , Paul Brook , qemu-devel@nongnu.org On 02/25/2010 11:33 AM, Avi Kivity wrote: > On 02/25/2010 07:15 PM, Anthony Liguori wrote: >>> I agree. Further, once we fine-grain device threading, the iothread >>> essentially disappears and is replaced by device-specific threads. >>> There's no "idle" anymore. >> >> >> That's a nice idea, but how is io dispatch handled? Is everything >> synchronous or do we continue to program asynchronously? > > Simple stuff can be kept asynchronous, complex stuff (like qcow2) > ought to be made synchronous (it uses threads anyway, so we don't lose > anything). Stuff like vnc can go either way. We've discussed this before and I still contend that threads do not make qcow2 any simpler. >> >> It's very difficult to mix concepts. > > We're complicated enough to have conflicting requirements and a large > code base with its own inertia, so no choice really. > >> I personally don't anticipate per-device threading but rather >> anticipate re-entrant device models. I would expect all I/O to be >> dispatched within the I/O thread and the VCPU threads to be able to >> execute device models simultaneously with the I/O thread. > > That means long-running operations on the iothread can lock out other > completions. > > Candidates for own threads are: > - live migration > - block format drivers (except linux-aio, perhaps have a thread for > the aio completion handler) > - vnc > - sdl > - sound? > - hotplug, esp. memory > > Each such thread could run the same loop as the iothread. Any > pollable fd or timer would be associated with a thread, so things > continue as normal more or less. Unassociated objects continue with > the main iothread. Is the point latency or increasing available CPU resources? If the device models are re-entrant, that reduces a ton of the demand on the qemu_mutex which means that IO thread can run uncontended. While we have evidence that the VCPU threads and IO threads are competing with each other today, I don't think we have any evidence to suggest that the IO thread is self-starving itself with long running events. With the device model, I'd like to see us move toward a very well defined API for each device to use. Part of the reason for this is to limit the scope of the devices in such a way that we can enforce this at compile time. Then we can introduce locking within devices with some level of guarantee that we've covered the API devices are actually consuming. For host services though, it's much more difficult to isolate them like this. I'm not necessarily claiming that this will never be the right thing to do, but I don't think we really have the evidence today to suggest that we should focus on this in the short term. Regards, Anthony Liguori