From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nkhau-0001pm-OU for qemu-devel@nongnu.org; Thu, 25 Feb 2010 12:33:48 -0500 Received: from [199.232.76.173] (port=42907 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nkhau-0001pa-91 for qemu-devel@nongnu.org; Thu, 25 Feb 2010 12:33:48 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1Nkhat-0002DR-Fd for qemu-devel@nongnu.org; Thu, 25 Feb 2010 12:33:48 -0500 Received: from mx1.redhat.com ([209.132.183.28]:61675) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Nkhat-0002DD-2s for qemu-devel@nongnu.org; Thu, 25 Feb 2010 12:33:47 -0500 Message-ID: <4B86B45B.5020507@redhat.com> Date: Thu, 25 Feb 2010 19:33:15 +0200 From: Avi Kivity 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> In-Reply-To: <4B86B044.6020501@codemonkey.ws> 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: Anthony Liguori Cc: Vadim Rozenfeld , Dor Laor , Christoph Hellwig , Paul Brook , qemu-devel@nongnu.org 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. > > 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. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.