From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kdm2m-0004NM-6F for qemu-devel@nongnu.org; Thu, 11 Sep 2008 09:17:08 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kdm2j-0004Mc-Ik for qemu-devel@nongnu.org; Thu, 11 Sep 2008 09:17:06 -0400 Received: from [199.232.76.173] (port=34222 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kdm2j-0004MS-Cs for qemu-devel@nongnu.org; Thu, 11 Sep 2008 09:17:05 -0400 Received: from mx2.redhat.com ([66.187.237.31]:38274) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kdm2i-0003bx-Rk for qemu-devel@nongnu.org; Thu, 11 Sep 2008 09:17:05 -0400 Message-ID: <48C91A00.3060403@redhat.com> Date: Thu, 11 Sep 2008 15:15:44 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <1221061788-26166-1-git-send-email-aliguori@us.ibm.com> <48C8CD4E.1020705@redhat.com> <48C91302.70207@us.ibm.com> In-Reply-To: <48C91302.70207@us.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH][RFC] Refactor AIO to allow multiple AIO implementations 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: Ryan Harper , qemu-devel@nongnu.org, kvm@vger.kernel.org Anthony Liguori wrote: > Gerd Hoffmann wrote: >> Hmm, what is the long-term plan for this? > > Step one is to move the generic aio bits out of block-raw-posix (which > this patch does). > > Step two is to move the posix-aio routines out of block-raw-posix. > > Step three would be to add a generic interface to allow block-raw-posix > to use multiple aio implementations > > Step four would be to add a new aio implementation Sounds good. > (I think the best > route is a thread-pool based implementation). Not sure about that. linux-aio would have the advantage that the kernel knows about all the requests in flight and probably can do a better job on I/O ordering and scheduling then. But once we can have multiple different implementations we can just try ;) cheers, Gerd