Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932225AbVK1UFK (ORCPT ); Mon, 28 Nov 2005 15:05:10 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932226AbVK1UFK (ORCPT ); Mon, 28 Nov 2005 15:05:10 -0500 Received: from mailout1.vmware.com ([65.113.40.130]:48650 "EHLO mailout1.vmware.com") by vger.kernel.org with ESMTP id S932225AbVK1UFI (ORCPT ); Mon, 28 Nov 2005 15:05:08 -0500 Message-ID: <438B62F3.4070801@vmware.com> Date: Mon, 28 Nov 2005 12:05:07 -0800 From: Zachary Amsden User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Davidsen Cc: Linus Torvalds , Alan Cox , "H. Peter Anvin" , Andi Kleen , Gerd Knorr , Dave Jones , Pavel Machek , Andrew Morton , Linux Kernel Mailing List , Zwane Mwaikambo , Pratap Subrahmanyam , Christopher Li , "Eric W. Biederman" , Ingo Molnar Subject: Re: [patch] SMP alternatives References: <1132764133.7268.51.camel@localhost.localdomain> <20051123163906.GF20775@brahms.suse.de> <1132766489.7268.71.camel@localhost.localdomain> <4384AECC.1030403@zytor.com> <1132782245.13095.4.camel@localhost.localdomain> <20051123214835.GA24044@nevyn.them.org> <20051123222056.GA25078@nevyn.them.org> <438B600C.1050604@tmr.com> In-Reply-To: <438B600C.1050604@tmr.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Nov 2005 20:05:06.0875 (UTC) FILETIME=[071F48B0:01C5F457] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1482 Lines: 35 Bill Davidsen wrote: > Linus Torvalds wrote: > >> >> In contrast, the simple silicon support scales wonderfully well. >> Suddenly libraries can be thread-safe _and_ efficient on UP too. You >> get to eat your cake and have it too. > > > I believe that a hardware solution would also accomodate the case > where a program runs unthreaded for most of the processing, and only > starts threads to do the final stage "report generation" tasks, where > that makes sense. I don't believe that it helps in the case where init > uses threads and then reverts to a single thread for the balance of > the task. I can't think of anything which does that, so it's probably > a non-critical corner case, or something the thread library could > correct. Startup routine of a scientific app calls a multithreaded "fetch work" routine, then crunches the data using a single thread. This could even happen somewhere inside a library, so the application itself is unaware that threads were ever invoked. This is not a far-fetched case. You really need per-address object notions of "threadedness" when talking about shared memory, since you may need shared memory to be atomic, but operate on the heap in single threaded fashion. Zach - 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/