From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KnLDY-0003qz-SI for qemu-devel@nongnu.org; Tue, 07 Oct 2008 18:39:48 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KnLDX-0003q3-D7 for qemu-devel@nongnu.org; Tue, 07 Oct 2008 18:39:48 -0400 Received: from [199.232.76.173] (port=39985 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KnLDX-0003pw-7p for qemu-devel@nongnu.org; Tue, 07 Oct 2008 18:39:47 -0400 Received: from el-out-1112.google.com ([209.85.162.179]:54158) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KnLDX-0008R1-4F for qemu-devel@nongnu.org; Tue, 07 Oct 2008 18:39:47 -0400 Received: by el-out-1112.google.com with SMTP id s27so748173ele.19 for ; Tue, 07 Oct 2008 15:39:45 -0700 (PDT) Message-ID: <48EBE52E.2070807@codemonkey.ws> Date: Tue, 07 Oct 2008 17:39:42 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] [5323] Implement an fd pool to get real AIO with posix-aio References: <48EB8393.8020005@redhat.com> <48EB87EE.9050003@codemonkey.ws> <48EBC932.9010808@redhat.com> <48EBD2C8.3040101@codemonkey.ws> <48EBDF6F.8080602@redhat.com> In-Reply-To: <48EBDF6F.8080602@redhat.com> 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: qemu-devel@nongnu.org Gerd Hoffmann wrote: > Anthony Liguori wrote: > >> Gerd Hoffmann wrote: >> >>> Anthony Liguori wrote: >>> >>> >>>>> Are there plans to support vectored block requests with the thread pool >>>>> implementation? >>>>> >>>>> >>>> Yes, that's the primary reason for doing a new thread pool >>>> implementation. >>>> >>>> >>> Cool. >>> >>> >>> >>>> Of course, we need a zero-copy DMA API before such a >>>> thing would make sense. >>>> >>>> >>> Hmm, quick check of the IDE code indeed shows a copy happening there. >>> Why is it needed? My xen disk backend doesn't copy data. Does that >>> mean might have done something wrong? Does the virtio backend copy data >>> too? >>> >> It does now, because the cost of splitting up the AIO request for each >> element of the scatter/gather list was considerably higher than the cost >> of copying the data to a linear buffer. >> > > Ok, so virtio will likely stop doing that soon I guess? With the aio > thread pool and even more with a vectored aio api the need for that > should go away ... > Right now, it's not a super high priority for us since we're getting good performance without it. More important is to improve emulated SCSI performance, get a proper zero copy API in, get virtio merged upstream, and then start tackling this stuff. >> You can only avoid doing a copy if you do something like phys_ram_base + >> PA. >> > > I actually do this ... > > void *xenner_mfn_to_ptr(xen_pfn_t pfn) > { > ram_addr_t offset; > > offset = cpu_get_physical_page_desc(pfn << PAGE_SHIFT); > return (void*)phys_ram_base + offset; > } > > ... which should keep working even in case there are holes in the guest > PA address space and thus guest_pa != phys_ram_base offset. > Yes, this is what we do in virtio too ATM. >> From an architectural perspective, this is not ideal since it >> doesn't allow for things like IOMMU emulation. What we need, is a >> zero-copy API at the PCI level. >> > > Sure, for IDE+SCSI emulation. For paravirtual drivers it shouldn't be > an issue. > For Xen, I can maybe see the argument that it shouldn't go through a DMA API since it's completely divorced of how normal hardware works. Since virtio drivers are really just a PCI device, I don't think that argument applies. There are good reasons to put in the effort to get a proper DMA API to improve SCSI and the e1000's performance. Regards, Anthony Liguori > cheers, > Gerd > > > > >