From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jamie Lokier Subject: Re: [Qemu-devel] Re: [PATCH][RFC] Refactor AIO to allow multiple AIO implementations Date: Thu, 11 Sep 2008 14:28:31 +0100 Message-ID: <20080911132831.GD16427@shareable.org> References: <1221061788-26166-1-git-send-email-aliguori@us.ibm.com> <48C8CD4E.1020705@redhat.com> <48C91302.70207@us.ibm.com> <48C91A00.3060403@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Anthony Liguori , Ryan Harper , kvm@vger.kernel.org To: qemu-devel@nongnu.org Return-path: Received: from mail2.shareable.org ([80.68.89.115]:49106 "EHLO mail2.shareable.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751731AbYIKN2h (ORCPT ); Thu, 11 Sep 2008 09:28:37 -0400 Content-Disposition: inline In-Reply-To: <48C91A00.3060403@redhat.com> Sender: kvm-owner@vger.kernel.org List-ID: Gerd Hoffmann wrote: > > (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 ;) Won't posix-aio give the same info to the kernel when used with a sufficiently avante-garde Linux distro? I'm under the impression that linux-aio is better in every way, as I think Anthony Liguori posted a while back: >>> Threads are a poor substitute for a proper AIO interface. >>> linux-aio gives you everything you could possibly want in an >>> interface since it allows you to submit multiple vectored operations >>> in a single syscall, use an fd to signal request completion, >>> complete multiple requests in a single syscall, and inject barriers >>> via fdsync. But knowing about request in flight, I/O ordering etc. seem equally available via posix-aio on a distro where that calls linux-aio (i.e. not the Glibc implementation). -- Jamie