Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755994AbYHMUnZ (ORCPT ); Wed, 13 Aug 2008 16:43:25 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753211AbYHMUmw (ORCPT ); Wed, 13 Aug 2008 16:42:52 -0400 Received: from one.firstfloor.org ([213.235.205.2]:41415 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752980AbYHMUmv (ORCPT ); Wed, 13 Aug 2008 16:42:51 -0400 To: Ingo Molnar Cc: Ulrich Drepper , Arjan van de Ven , akpm@linux-foundation.org, hugh@veritas.com, linux-mm@kvack.org, linux-kernel@vger.kernel.org, briangrant@google.com, cgd@google.com, mbligh@google.com, Linus Torvalds , Thomas Gleixner , "H. Peter Anvin" Subject: Re: pthread_create() slow for many threads; also time to revisit 64b context switch optimization? From: Andi Kleen References: <20080813104445.GA24632@elte.hu> <20080813063533.444c650d@infradead.org> <48A2EE07.3040003@redhat.com> <20080813142529.GB21129@elte.hu> <48A2F157.7000303@redhat.com> <20080813151007.GA8780@elte.hu> Date: Wed, 13 Aug 2008 22:42:48 +0200 In-Reply-To: <20080813151007.GA8780@elte.hu> (Ingo Molnar's message of "Wed, 13 Aug 2008 17:10:07 +0200") Message-ID: <87fxp8zlx3.fsf@basil.nowhere.org> User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1381 Lines: 30 Ingo Molnar writes: > > i find it pretty unacceptable these days that we limit any aspect of > pure 64-bit apps in any way to 4GB (or any other 32-bit-ish limit). It's not limited to 2GB, there's a fallback to >4GB of course. Ok admittedly the fallback is slow, but it's there. I would prefer to not slow down the P4s. There are **lots** of them in field. And they ran 64bit still quite well. Also back then I benchmarked on early K8 and it also made a difference there (but I admit I forgot the numbers) I think it would be better to fix the VM because there are other use cases of applications who prefer to allocate in a lower area. For example Java JVMs now widely use a technique called pointer compression where they dynamically adjust the pointer size based on how much memory the process uses. For that you have to get low memory in the 47bit VM too. The VM should deal with that gracefully. To be honest I always thought the linear search in the VMA list was a little dumb. I'm sure there are other cases where it hurts too. Perhaps this would be really an opportunity to do something about it :) -Andi -- 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/