Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932219AbVK1UXO (ORCPT ); Mon, 28 Nov 2005 15:23:14 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932232AbVK1UXO (ORCPT ); Mon, 28 Nov 2005 15:23:14 -0500 Received: from prgy-npn2.prodigy.com ([207.115.54.38]:37380 "EHLO oddball.prodigy.com") by vger.kernel.org with ESMTP id S932219AbVK1UXN (ORCPT ); Mon, 28 Nov 2005 15:23:13 -0500 Message-ID: <438B679F.5050207@tmr.com> Date: Mon, 28 Nov 2005 15:25:03 -0500 From: Bill Davidsen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.11) Gecko/20050729 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Linus Torvalds CC: Alan Cox , "H. Peter Anvin" , Andi Kleen , Gerd Knorr , Dave Jones , Zachary Amsden , 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: <438359D7.7090308@suse.de> <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> <20051125073854.GA16771@taniwha.stupidest.org> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2709 Lines: 56 Linus Torvalds wrote: > > On Thu, 24 Nov 2005, Chris Wedgwood wrote: > >>CPUs in embedded the space could outnumber desktops & servers greatly >>(cell phones, access pointers, routers, media players, etc). Most of >>these will be UP for some time. > > > That's not entirely clear either. > > There are definite advantages to SMP even in the embedded space - or, to > put it more strongly: _especially_ in the embedded space. > I would argue that there is no "the embedded space," but rather a set of embedded spaces with various needs. Having worked doing industrial control for three years and lunched with IC folks another decade, I'm fairly sure that consumer goods are very different from real industrial control, a realtime items (multimedia) are different than phones and PDAs. Until the phone gets "swear at it" slow, features like voice recognition are more important than doing voice to number lookup in 20ms instead of 400ms. Cost and battery life matter a lot too, while the media and IC markets are already attached to expensive stuff, so the computer is is smaller fraction of the cost. > None of the cellphone manufacturers seem to be in the least interested in > doing a "phone only" solution. They can already do that cheaply, they > can't make much money off it, and they are all interested in features. And > it really _is_ more power-efficient to have, say, a dual-core 200MHz chip > than it is to have a single-core 300MHz one. > > Now, sometimes those SMP systems will actually be used as "tightly coupled > UP", where one of the CPU's is just basically a DSP. And from a power > efficiency standpoint, having specialized hardware (and thus _A_MP rather > than SMP) is obviously better, but in complex tasks - and communication > tends to be that - general-purpose is often desirable enough that people > will take the inefficiencies of a GP CPU over a fixed-function specialized > DSP-kind of environment. > > But SMP is absolutely _not_ unusual in embedded. It's been there for years > already, and it's clearly moving downwards there too. Absolutely true, but that dual core 200 MHz chip probably draws more power than a 200 MHz uni, etc. So there will probably be uni applications for the forseeable future, any benefit in uni performance will be useful. -- -bill davidsen (davidsen@tmr.com) "The secret to procrastination is to put things off until the last possible moment - but no longer" -me - 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/