From mboxrd@z Thu Jan 1 00:00:00 1970 From: Gerd Hoffmann Subject: Re: [PATCH][RFC] Refactor AIO to allow multiple AIO implementations Date: Thu, 11 Sep 2008 09:48:30 +0200 Message-ID: <48C8CD4E.1020705@redhat.com> References: <1221061788-26166-1-git-send-email-aliguori@us.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: qemu-devel@nongnu.org, Ryan Harper , kvm@vger.kernel.org To: Anthony Liguori Return-path: Received: from mx2.redhat.com ([66.187.237.31]:53805 "EHLO mx2.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751583AbYIKHu2 (ORCPT ); Thu, 11 Sep 2008 03:50:28 -0400 In-Reply-To: <1221061788-26166-1-git-send-email-aliguori@us.ibm.com> Sender: kvm-owner@vger.kernel.org List-ID: Anthony Liguori wrote: > This patch refactors the AIO layer to allow multiple AIO implementations. It's > only possible because of the recent signalfd() patch. > > Right now, the AIO infrastructure is pretty specific to the block raw backend. > For other block devices to implement AIO, the qemu_aio_wait function must support > registration. This patch introduces a new function, qmeu_aio_set_fd_handler, which > can be used to register a file descriptor to be called back. qemu_aio_wait() now > polls a set of file descriptors registered with this function until one becomes > readable or writable. Hmm, what is the long-term plan for this? Separating out the completion notification is a nice first step. Most of the aio infrastructure is still in the block raw backend though. IMHO it doesn't belong there. The aio implementation(s) should be a separate entity usable by all block backends to invoke aio requests, without having to care about how this is actually implemented (threads, linux aio, posix aio, whatever). cheers, Gerd From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Kdgw6-0004Q8-6P for qemu-devel@nongnu.org; Thu, 11 Sep 2008 03:49:54 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Kdgw4-0004Ot-Td for qemu-devel@nongnu.org; Thu, 11 Sep 2008 03:49:53 -0400 Received: from [199.232.76.173] (port=38796 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Kdgw4-0004OW-DQ for qemu-devel@nongnu.org; Thu, 11 Sep 2008 03:49:52 -0400 Received: from mx2.redhat.com ([66.187.237.31]:34891) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Kdgw3-0006GQ-Se for qemu-devel@nongnu.org; Thu, 11 Sep 2008 03:49:52 -0400 Message-ID: <48C8CD4E.1020705@redhat.com> Date: Thu, 11 Sep 2008 09:48:30 +0200 From: Gerd Hoffmann MIME-Version: 1.0 References: <1221061788-26166-1-git-send-email-aliguori@us.ibm.com> In-Reply-To: <1221061788-26166-1-git-send-email-aliguori@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: > This patch refactors the AIO layer to allow multiple AIO implementations. It's > only possible because of the recent signalfd() patch. > > Right now, the AIO infrastructure is pretty specific to the block raw backend. > For other block devices to implement AIO, the qemu_aio_wait function must support > registration. This patch introduces a new function, qmeu_aio_set_fd_handler, which > can be used to register a file descriptor to be called back. qemu_aio_wait() now > polls a set of file descriptors registered with this function until one becomes > readable or writable. Hmm, what is the long-term plan for this? Separating out the completion notification is a nice first step. Most of the aio infrastructure is still in the block raw backend though. IMHO it doesn't belong there. The aio implementation(s) should be a separate entity usable by all block backends to invoke aio requests, without having to care about how this is actually implemented (threads, linux aio, posix aio, whatever). cheers, Gerd