Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758287AbYHONcM (ORCPT ); Fri, 15 Aug 2008 09:32:12 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753694AbYHONb5 (ORCPT ); Fri, 15 Aug 2008 09:31:57 -0400 Received: from one.firstfloor.org ([213.235.205.2]:48069 "EHLO one.firstfloor.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753399AbYHONb4 (ORCPT ); Fri, 15 Aug 2008 09:31:56 -0400 Date: Fri, 15 Aug 2008 15:33:22 +0200 From: Andi Kleen To: Ingo Molnar Cc: Andi Kleen , 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? Message-ID: <20080815133322.GH19125@one.firstfloor.org> 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> <87fxp8zlx3.fsf@basil.nowhere.org> <20080815124350.GA26594@elte.hu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20080815124350.GA26594@elte.hu> User-Agent: Mutt/1.4.2.1i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1511 Lines: 38 On Fri, Aug 15, 2008 at 02:43:50PM +0200, Ingo Molnar wrote: > i had such a P4 based 64-bit box and it was painful. I used them as 64bit machines and they weren't painful at all. > I'd love to zap MAP_32BIT this very minute from the kernel, but you > originally shaped the whole thing in such a stupid way that makes its > elimination impossible now due to ABI constraints. It would have cost MAP_32BIT was not actually added for this originally. It was originally added for the X server's old dynamic loader, which needed 2GB memory. It's main failing, which I freely admit, was to not call it MAP_31BIT. > you _nothing_ to have added MAP_64BIT_STACK back then, but the quick & Not sure what the semantics of that would be. For me it would seem ugly to hardcode specific semantics in the kernel for this ("mechanism not policy") But for most possible semantics I can think of the data structure would still need to be fixed I think. > The correct solution is to eliminate this flag from glibc right now, and IMHO the correct solution is to fix the data structure to not have such a bad complexity in this corner case. We typically do this for all other data structures as we discover such cases. No reason the VMAs should be any different. -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/