Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932540AbVKWVgx (ORCPT ); Wed, 23 Nov 2005 16:36:53 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932542AbVKWVgx (ORCPT ); Wed, 23 Nov 2005 16:36:53 -0500 Received: from smtp.osdl.org ([65.172.181.4]:28052 "EHLO smtp.osdl.org") by vger.kernel.org with ESMTP id S932540AbVKWVgw (ORCPT ); Wed, 23 Nov 2005 16:36:52 -0500 Date: Wed, 23 Nov 2005 13:36:08 -0800 (PST) From: Linus Torvalds To: Alan Cox cc: "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 In-Reply-To: <1132782245.13095.4.camel@localhost.localdomain> Message-ID: References: <4378A7F3.9070704@suse.de> <4379ECC1.20005@suse.de> <437A0649.7010702@suse.de> <437B5A83.8090808@suse.de> <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> 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: 1772 Lines: 41 On Wed, 23 Nov 2005, Alan Cox wrote: > > There is a much much better way to do it than just user space and > without hitting cr3/cr4 - put "lock works" in the PAT and while we'll > have to add PAT support which we need to do anyway we would get a world > where on uniprocessor lock prefix only works on addresse targets we want > it to - ie pci_alloc_consistent() pages. No. That would be wrong. The thing is, "lock" is useless EVEN ON SMP in user space 99% of the time. Think of all the thread locking in libc - where 99% of all processes are single-threaded, and it does nothing but slow things down. Actual UP machines are going to go away - even ARM is going SMP, and in the PC space, we'll have multi-core laptops probably being the rule rather than the exception in a couple of years. So the kernel will need "lock" in the forseeable future, and optimizing for UP is a lost game. But optimizing for a single _thread_ is not a lost game. I don't believe that threaded applications are necessarily going to take over all that much in a lot of areas. Sure, we'll have more threaded apps too, but we'll continue to have tons more of performance-critical non-threaded things like compilers etc. And _that_ is worth optimizing for. General libraries that have to be able to handle the threaded case dynamically, but that are often run with no shared memory anywhere. THAT is what I'd like to have CPU support for. Not for UP (it's going away), and not for the kernel (it's never single-threaded). 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/