From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LB6bV-0008DU-FN for qemu-devel@nongnu.org; Fri, 12 Dec 2008 06:54:45 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LB6bU-0008DC-NO for qemu-devel@nongnu.org; Fri, 12 Dec 2008 06:54:44 -0500 Received: from [199.232.76.173] (port=56674 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LB6bU-0008D9-IL for qemu-devel@nongnu.org; Fri, 12 Dec 2008 06:54:44 -0500 Received: from brick.kernel.dk ([93.163.65.50]:21175 helo=kernel.dk) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LB6bU-0003hN-4e for qemu-devel@nongnu.org; Fri, 12 Dec 2008 06:54:44 -0500 Date: Fri, 12 Dec 2008 12:54:21 +0100 From: Jens Axboe Subject: Re: [Qemu-devel] [RFC] Replace posix-aio with custom thread pool Message-ID: <20081212115420.GR23742@kernel.dk> References: <20081210190810.GG18814@random.random> <20081211131222.GA14908@random.random> <494130B5.2080800@redhat.com> <20081211155335.GE14908@random.random> <49413B9C.3030703@redhat.com> <20081211164947.GD6809@random.random> <49414BC9.5090905@redhat.com> <20081211181116.GE6809@random.random> <20081212082309.GI23742@kernel.dk> <20081212115133.GI6809@random.random> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20081212115133.GI6809@random.random> 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: qemu-devel@nongnu.org, kvm-devel , Gerd Hoffmann On Fri, Dec 12 2008, Andrea Arcangeli wrote: > On Fri, Dec 12, 2008 at 09:23:10AM +0100, Jens Axboe wrote: > > aio is only async with O_DIRECT, with buffered IO it's sync. > > That's very bad, because aio is as needed for O_DIRECT as for buffered > read seeking workloads that otherwise have zero chance to fill the > I/O pipe... (well unless one is threading in userland which is obviously > less efficient than what aio could achieve in kernel space, even I agree completely. The buffered aio patches got pretty involved though, it wasn't real pretty in the end. So it never got merged. Looks like the most realistic way forward is some variant of syslet (or the acall stuff that Zach has been working on), which is largely a cop out and will never perform as well. > without taking cfq screwed bucketing into account). I added CLONE_IO some time ago to avoid that, so it's perfectly possible to share cfq io contexts with threads or processes even in userspace! -- Jens Axboe