|| ||Ingo Molnar <mingo-AT-elte.hu>|
|| ||Ulrich Drepper <drepper-AT-gmail.com>|
|| ||Re: pthread_create() slow for many threads; also time to revisit
64b context switch optimization?|
|| ||Fri, 15 Aug 2008 19:19:13 +0200|
|| ||Jamie Lokier <jamie-AT-shareable.org>,
Arjan van de Ven <arjan-AT-infradead.org>,
akpm-AT-linux-foundation.org, hugh-AT-veritas.com, linux-mm-AT-kvack.org,
Linus Torvalds <torvalds-AT-linux-foundation.org>,
Thomas Gleixner <tglx-AT-linutronix.de>,
"H. Peter Anvin" <hpa-AT-zytor.com>|
* Ulrich Drepper <firstname.lastname@example.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Jamie Lokier wrote:
> > Suggest:
> > +#define MAP_STACK 0x20000 /* 31bit or 64bit address for stack, */
> > + /* whichever is faster on this CPU */
> I agree. Except for the comment.
> > Also, is this _only_ useful for thread stacks, or are there other
> > memory allocations where 31-bitness affects execution speed on old P4s?
> Actually, I would define the flag as "do whatever is best assuming the
> allocation is used for stacks".
> For instance, minimally the /proc/*/maps output could show "[user
> stack]" or something like this. For security, perhaps, setting of
> PROC_EXEC can be prevented.
makes sense. Updated patch below. I've also added your Acked-by. Queued
it up in tip/x86/urgent, for v2.6.27 merging.
( also, just to make sure: all Linux kernel versions will ignore such
extra flags, so you can just update glibc to use this flag
unconditionally, correct? )
From 2fdc86901d2ab30a12402b46238951d2a7891590 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <email@example.com>
Date: Wed, 13 Aug 2008 18:02:18 +0200
Subject: [PATCH] x86: add MAP_STACK mmap flag
as per this discussion:
Pardo reported that 64-bit threaded apps, if their stacks exceed the
combined size of ~4GB, slow down drastically in pthread_create() - because
glibc uses MAP_32BIT to allocate the stacks. The use of MAP_32BIT is
a legacy hack - to speed up context switching on certain early model
64-bit P4 CPUs.
So introduce a new flag to be used by glibc instead, to not constrain
64-bit apps like this.
glibc can switch to this new flag straight away - it will be ignored
by the kernel. If those old CPUs ever matter to anyone, support for
it can be implemented.
Signed-off-by: Ingo Molnar <firstname.lastname@example.org>
Acked-by: Ulrich Drepper <email@example.com>
include/asm-x86/mman.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/include/asm-x86/mman.h b/include/asm-x86/mman.h
index c1682b5..90bc410 100644
@@ -12,6 +12,7 @@
#define MAP_NORESERVE 0x4000 /* don't check for reservations */
#define MAP_POPULATE 0x8000 /* populate (prefault) pagetables */
#define MAP_NONBLOCK 0x10000 /* do not block on IO */
+#define MAP_STACK 0x20000 /* give out an address that is best suited for process/thread stacks
#define MCL_CURRENT 1 /* lock all current mappings */
#define MCL_FUTURE 2 /* lock all future mappings */
to post comments)