Re: pthread_create() slow for many threads; also time to revisit
64b context switch optimization?
[Posted August 19, 2008 by corbet]
| From: |
| Ingo Molnar <mingo-AT-elte.hu> |
| To: |
| Ulrich Drepper <drepper-AT-gmail.com> |
| Subject: |
| Re: pthread_create() slow for many threads; also time to revisit
64b context switch optimization? |
| Date: |
| Fri, 15 Aug 2008 19:19:13 +0200 |
| Message-ID: |
| <20080815171913.GB23600@elte.hu> |
| Cc: |
| 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,
linux-kernel-AT-vger.kernel.org, briangrant-AT-google.com,
cgd-AT-google.com, mbligh-AT-google.com,
Linus Torvalds <torvalds-AT-linux-foundation.org>,
Thomas Gleixner <tglx-AT-linutronix.de>,
"H. Peter Anvin" <hpa-AT-zytor.com> |
| Archive-link: |
| Article,
Thread
|
* Ulrich Drepper <drepper@gmail.com> 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? )
Ingo
--------------------------->
From 2fdc86901d2ab30a12402b46238951d2a7891590 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@elte.hu>
Date: Wed, 13 Aug 2008 18:02:18 +0200
Subject: [PATCH] x86: add MAP_STACK mmap flag
as per this discussion:
http://lkml.org/lkml/2008/8/12/423
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 <mingo@elte.hu>
Acked-by: Ulrich Drepper <drepper@gmail.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
--- a/include/asm-x86/mman.h
+++ b/include/asm-x86/mman.h
@@ -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 */
(
Log in to post comments)