Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1030513AbXBFXFV (ORCPT ); Tue, 6 Feb 2007 18:05:21 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1030519AbXBFXFU (ORCPT ); Tue, 6 Feb 2007 18:05:20 -0500 Received: from smtp.osdl.org ([65.172.181.24]:54639 "EHLO smtp.osdl.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1030513AbXBFXFS (ORCPT ); Tue, 6 Feb 2007 18:05:18 -0500 Date: Tue, 6 Feb 2007 15:04:51 -0800 (PST) From: Linus Torvalds To: Kent Overstreet cc: Davide Libenzi , 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 In-Reply-To: <6f703f960702061445q23dd9d48q7afec75d2400ef62@mail.gmail.com> Message-ID: References: <20070203082308.GA6748@elte.hu> <8CF4BE18-8EEF-4ACA-A4B4-B627ED3B4831@oracle.com> <6f703f960702051331v3ceab725h68aea4cd77617f84@mail.gmail.com> <6f703f960702061445q23dd9d48q7afec75d2400ef62@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1401 Lines: 37 On Tue, 6 Feb 2007, Kent Overstreet wrote: > > The "struct aiocb" isn't something you have to or necessarily want to > keep around. Oh, don't get me wrong - the _only_ reason for "struct aiocb" would be backwards compatibility. The point is, we'd need to keep that compatibility to be useful - otherwise we just end up having to duplicate the work (do _both_ fibrils _and_ the in-kernel AIO). > I don't see the point in having a ring for completed events, since > it's at most two pointers per completion; quite a bit less data being > sent back than for submissions. I'm certainly personally perfectly happy with the kernel not remembering any completed events at all - once it's done, it's done and forgotten. So doing async(mycookie) wait_for_async(mycookie) could actually return with -ECHILD (or similar error). In other words, if you see it as a "process interface" (instead of as a "filedescriptor interface"), I'd suggest automatic reaping of the fibril children. I do *not* think we want the equivalent of zombies - if only because they are just a lot of work to reap, and potentially a lot of memory to keep around. Linus - 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/