From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LlqHG-0003xq-CS for qemu-devel@nongnu.org; Mon, 23 Mar 2009 15:57:42 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LlqHB-0003tg-Ni for qemu-devel@nongnu.org; Mon, 23 Mar 2009 15:57:41 -0400 Received: from [199.232.76.173] (port=44874 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LlqHB-0003td-J1 for qemu-devel@nongnu.org; Mon, 23 Mar 2009 15:57:37 -0400 Received: from mx2.redhat.com ([66.187.237.31]:37835) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LlqHB-0006cz-0H for qemu-devel@nongnu.org; Mon, 23 Mar 2009 15:57:37 -0400 Message-ID: <49C7E9CE.50506@redhat.com> Date: Mon, 23 Mar 2009 21:58:06 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH][RFC] Linux AIO support when using O_DIRECT References: <1237823124-6417-1-git-send-email-aliguori@us.ibm.com> <49C7B620.8030203@redhat.com> <49C7C392.3030001@codemonkey.ws> In-Reply-To: <49C7C392.3030001@codemonkey.ws> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, kvm@vger.kernel.org Anthony Liguori wrote: > Avi Kivity wrote: >> >> Instead of introducing yet another layer of indirection, you could >> add block-raw-linux-aio, which would be registered before >> block-raw-posix (which is realy block-raw-threadpool...), and resist >> a ->probe() if caching is enabled. > > block-raw-posix needs a major overhaul. That's why I'm not even > considering committing the patch as is. That would suggest block-raw-linux-aio-bork-bork-bork.c even more, no? > > I'd like to see the O_DIRECT bounce buffering removed in favor of the > DMA API bouncing. Once that happens, raw_read and raw_pread can > disappear. block-raw-posix becomes much simpler. They aren't really related... note that DMA API requests are likely to be aligned anyway, since the guest generates them with the expectation that alignent is required. We need to align at a lower level so we can take care of non-dma-api callers (mostly qemu internal). > > We would drop the signaling stuff and have the thread pool use an fd > to signal. The big problem with that right now is that it'll cause a > performance regression for certain platforms until we have the IO > thread in place. Well, let's merge this after the iothread? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.