From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LBCaU-0005iL-3R for qemu-devel@nongnu.org; Fri, 12 Dec 2008 13:18:06 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LBCaS-0005hd-KA for qemu-devel@nongnu.org; Fri, 12 Dec 2008 13:18:05 -0500 Received: from [199.232.76.173] (port=38448 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LBCaS-0005hS-8n for qemu-devel@nongnu.org; Fri, 12 Dec 2008 13:18:04 -0500 Received: from qw-out-1920.google.com ([74.125.92.148]:53614) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LBCaR-0001NH-Tq for qemu-devel@nongnu.org; Fri, 12 Dec 2008 13:18:04 -0500 Received: by qw-out-1920.google.com with SMTP id 5so419781qwc.4 for ; Fri, 12 Dec 2008 10:18:03 -0800 (PST) Message-ID: <4942AAD6.1090408@codemonkey.ws> Date: Fri, 12 Dec 2008 12:17:58 -0600 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [RFC] Replace posix-aio with custom thread pool References: <493FFAB6.2000106@codemonkey.ws> <493FFC8E.9080802@redhat.com> <49400F69.8080707@codemonkey.ws> <20081210190810.GG18814@random.random> <20081212142435.GL6809@random.random> <494276CD.6060904@codemonkey.ws> <20081212154418.GM6809@random.random> <49429629.20309@codemonkey.ws> <20081212170916.GO6809@random.random> <49429EA3.8070008@codemonkey.ws> <20081212175213.GP6809@random.random> In-Reply-To: <20081212175213.GP6809@random.random> 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: Andrea Arcangeli Cc: Gerd Hoffmann , kvm-devel , qemu-devel@nongnu.org Andrea Arcangeli wrote: > On Fri, Dec 12, 2008 at 11:25:55AM -0600, Anthony Liguori wrote: > >> Hrm, that's more complex than I was expecting. I was thinking the bdrv aio >> infrastructure would always take an iovec. Any details about the >> underlying host's ability to handle the iovec would be insulated. >> > > You can't remove the restart memory-capped mechanism from the dma api, > we've to handle dma to non-ram that potentially requires to copy the > whole buffer so we're forced to have a safe linearization at the dma > api layer. So it's not necessary to reinvent the same > restart-partial-transfer logic in the aio layer too. Just set the > define and teach the aio logic to use pread/pwrite if iovcnt == 1 and > you're done ;). > > So what I'm suggesting is simpler than what you were expecting, not > more complex. It would be more complex to replicate the restart-bounce > logic in the aio layer too. > > Old drivers using bdrv_aio_read/write will keep working, new drivers > using dma api can also use bdrv_aio_readv/writev and the linearization > will happen inside the dma api if aio misses preadv/pwritev support. > You assume that anything using bdrv_aio_readv/writev will be going through a DMA API. This isn't a safe assumption. Furthermore, you need some way to communicate the fact that you cannot handle iovcnt > 1 iovecs in a performant/safe way. Regards, Anthony Liguori