Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1946151AbXBBXTL (ORCPT ); Fri, 2 Feb 2007 18:19:11 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1946156AbXBBXTK (ORCPT ); Fri, 2 Feb 2007 18:19:10 -0500 Received: from smtp.osdl.org ([65.172.181.24]:44135 "EHLO smtp.osdl.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1946151AbXBBXTJ (ORCPT ); Fri, 2 Feb 2007 18:19:09 -0500 Date: Fri, 2 Feb 2007 15:17:57 -0800 (PST) From: Linus Torvalds To: Ingo Molnar cc: Alan , Zach Brown , linux-kernel@vger.kernel.org, linux-aio@kvack.org, Suparna Bhattacharya , Benjamin LaHaise Subject: Re: [PATCH 2 of 4] Introduce i386 fibril scheduling In-Reply-To: Message-ID: References: <20070201083611.GC18233@elte.hu> <20070202104900.GA13941@elte.hu> <20070202195932.15b9b4ed@localhost.localdomain> <20070202213019.202e8db5@localhost.localdomain> <20070202224259.GB1212@elte.hu> 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: 1716 Lines: 39 On Fri, 2 Feb 2007, Linus Torvalds wrote: > On Fri, 2 Feb 2007, Ingo Molnar wrote: > > > > but if the application /has/ identified fundamental parallelism, we > > /must not/ shut that parallelism off by /designing/ this interface to > > use the fibril thing which is a limited cooperative, single-CPU entity. > > Right. We should for example encourage people to use some kind of > paralellizing construct. > > I know! We could even call them "threads", so to give people the idea that > they are independent smaller entities in a thicker "rope", and we could > call that bigger entity a "task" or "process", since it "processes" data. > > Or is that just too far out? So the above was obviously tongue-in-cheek, but you should really think about the context here. We're discussing doing *single* system calls. There is absolutely zero point to try to parallelize the work over multiple CPU's or threads. We're literally talking about doing things where the actual CPU cost is in the hundreds of nanoseconds, and where traditionally a rather noticeable part of the cost is not the code itself, but the high cost of taking a system call trap, and saving all the register state. When parallelising "real work", I absolutely agree with you: we should use threads. But you need to look at what it is we parallelize here, and ask yourself why we're doing what we're doing, and why people aren't *already* just using a separate thread for it. 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/