From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JrzwH-0003Q3-4R for qemu-devel@nongnu.org; Fri, 02 May 2008 14:24:57 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JrzwE-0003Pr-N7 for qemu-devel@nongnu.org; Fri, 02 May 2008 14:24:55 -0400 Received: from [199.232.76.173] (port=34616 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JrzwE-0003Po-IA for qemu-devel@nongnu.org; Fri, 02 May 2008 14:24:54 -0400 Received: from mail2.shareable.org ([80.68.89.115]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1JrzwE-0004CF-78 for qemu-devel@nongnu.org; Fri, 02 May 2008 14:24:54 -0400 Received: from jamie by mail2.shareable.org with local (Exim 4.63) (envelope-from ) id 1JrzwB-0000ms-UE for qemu-devel@nongnu.org; Fri, 02 May 2008 19:24:51 +0100 Date: Fri, 2 May 2008 19:24:51 +0100 From: Jamie Lokier Subject: Re: [kvm-devel] [Qemu-devel] Re: [PATCH 1/3] Refactor AIO interface to allow other AIO implementations Message-ID: <20080502182451.GB2827@shareable.org> References: <20080420233913.GA23292@shareable.org> <480C36A3.6010900@qumranet.com> <20080421121028.GD4193@shareable.org> <480D9D74.5070801@qumranet.com> <20080422142847.GC4849@shareable.org> <480DFE43.8060509@qumranet.com> <20080422153616.GC10229@shareable.org> <69304d110805020937l2f867cadrd7c906b8eb77b3f6@mail.gmail.com> <20080502171823.GA1240@shareable.org> <481B54DC.6040409@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <481B54DC.6040409@codemonkey.ws> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Anthony Liguori wrote: > FWIW, in the process of optimizing the kernel driver for virtio-blk, > I've found that using a no-op scheduler helps a fair bit. As long as > you're using a reasonably sized ring, the back-end can merge adjacent > requests. This also helps a fair bit too. By 'back-end' do you mean the virtio-blk driver itself merges requests? I'm assuming yes, for these questions: Does it honour barriers properly? Isn't that the job of the guest elevator? Does it suggest the various guest I/O schedulers could be enhanced to operate directly on requests in flight in the virtio ring? Oh, one last thing. Is it plausible to write a Windows driver which uses the virtio-blk interface, to get the best performing Windows-in-KVM? (It's nice to be able to say Linux makes a good host for Windows guests too.) Thanks, - Jamie