Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S933272AbXBGApR (ORCPT ); Tue, 6 Feb 2007 19:45:17 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S933274AbXBGApQ (ORCPT ); Tue, 6 Feb 2007 19:45:16 -0500 Received: from rgminet01.oracle.com ([148.87.113.118]:44402 "EHLO rgminet01.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933272AbXBGApP (ORCPT ); Tue, 6 Feb 2007 19:45:15 -0500 Date: Tue, 6 Feb 2007 16:44:43 -0800 From: Joel Becker To: Davide Libenzi Cc: Kent Overstreet , Linus Torvalds , Zach Brown , Ingo Molnar , Linux Kernel Mailing List , linux-aio@kvack.org, Suparna Bhattacharya , Benjamin LaHaise Subject: Re: [PATCH 2 of 4] Introduce i386 fibril scheduling Message-ID: <20070207004443.GE32307@ca-server1.us.oracle.com> Mail-Followup-To: Davide Libenzi , Kent Overstreet , Linus Torvalds , Zach Brown , Ingo Molnar , Linux Kernel Mailing List , linux-aio@kvack.org, Suparna Bhattacharya , Benjamin LaHaise References: <6f703f960702051331v3ceab725h68aea4cd77617f84@mail.gmail.com> <6f703f960702061445q23dd9d48q7afec75d2400ef62@mail.gmail.com> <20070206233907.GW32307@ca-server1.us.oracle.com> <20070207000626.GC32307@ca-server1.us.oracle.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Burt-Line: Trees are cool. X-Red-Smith: Ninety feet between bases is perhaps as close as man has ever come to perfection. User-Agent: Mutt/1.5.11 X-Brightmail-Tracker: AAAAAQAAAAI= X-Brightmail-Tracker: AAAAAQAAAAI= X-Whitelist: TRUE X-Whitelist: TRUE Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1723 Lines: 48 On Tue, Feb 06, 2007 at 04:23:52PM -0800, Davide Libenzi wrote: > To how many "sessions" those 1000 *parallel* I/O operations refer to? > Because, if you batch them in an async fashion, they have to be parallel. They're independant. Of course they have to be parallel, that's what I/O wants. > Without the per-async operation status code, you'll need to wait a result > *for each* submitted syscall, even the ones that completed syncronously. You are right, but it's more efficient in some cases. > Open questions are: > > - Is the 1000 *parallel* syscall vectored submission case common? Sure is for I/O. It's the majority of the case. If you have 1000 blocks to send out, you want them all down at the request queue at once, where they can merge. > - Is it more expensive to forcibly have to wait and fetch a result even > for in-cache syscalls, or it's faster to walk the submission array? Not everything is in-cache. Databases will be doing O_DIRECT and will expect that 90% of their I/O calls will block. Why should they have to iterate this list every time? If this is the API, they *have* to. If there's an efficient way to get "just the ones that didn't block", then it's not a problem. Joel -- "The real reason GNU ls is 8-bit-clean is so that they can start using ISO-8859-1 option characters." - Christopher Davis (ckd@loiosh.kei.com) Joel Becker Principal Software Developer Oracle E-mail: joel.becker@oracle.com Phone: (650) 506-8127 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/