From mboxrd@z Thu Jan 1 00:00:00 1970 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 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