Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753053AbYHMP4o (ORCPT ); Wed, 13 Aug 2008 11:56:44 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750914AbYHMP4g (ORCPT ); Wed, 13 Aug 2008 11:56:36 -0400 Received: from mx1.redhat.com ([66.187.233.31]:60317 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750781AbYHMP4f (ORCPT ); Wed, 13 Aug 2008 11:56:35 -0400 Message-ID: <48A303EE.8070002@redhat.com> Date: Wed, 13 Aug 2008 08:55:26 -0700 From: Ulrich Drepper Organization: Red Hat, Inc. User-Agent: Thunderbird 2.0.0.16 (X11/20080723) MIME-Version: 1.0 To: Ingo Molnar CC: 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? 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> <48A2FC17.9070302@redhat.com> <20080813154043.GA11886@elte.hu> In-Reply-To: <20080813154043.GA11886@elte.hu> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1320 Lines: 37 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Ingo Molnar wrote: > Btw., can you see any problems with option #1: simply removing MAP_32BIT > from 64-bit stack allocations in glibc unconditionally? Yes, as we both agree, there are still such machines out there. The real problem is: what to do if somebody complains? If we would have the extra flag such people could be accommodated. If there is no such flag then distributions cannot just add the flag (it's part of the kernel API) and they would be caught between a rock and a hard place. Option #2 provides the biggest flexibility. I upstream kernel truly doesn't care about such machines anymore there are two options: - - really do nothing at all - - at least reserve a flag in case somebody wants/has to implement option #2 - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkijA+4ACgkQ2ijCOnn/RHRhLQCdGNvwikwY4hMHBuYUP4WDqsy3 cfcAn2hrN1MoOkN3UIC4iSUCtqD2Yl6W =yG5T -----END PGP SIGNATURE----- -- 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/