Messages in this thread | | | Date | Tue, 27 Jan 2004 20:57:13 +0100 | From | Andi Kleen <> | Subject | Re: linux-2.6.1 x86_64 : STACK_TOP and text/data |
| |
On Tue, 27 Jan 2004 20:45:24 +0100 dada1 <dada1@cosmosbay.com> wrote:
> Another thing I noticed in last glibc CVS (nptl) > > Thread stacks are also allocated in the 1GB quadrant : > > nptl/sysdeps/x86_64/pthreaddef.h > /* We prefer to have the stack allocated in the low 4GB since this > allows faster context switches. */ > #define ARCH_MAP_FLAGS MAP_32BIT > > Is this really true ? > Is memory allocated in the low 4GB is faster on x86_64 (64bit kernel, > 64 bit user prog ?)
That only applies to areas referenced set by set_thread_area() and referenced by segment registers. For pointers <4GB it can use a faster method at context switch.
They probably do that because they put the thread local data at the bottom of the stack and it has to be referenced using %gs. They should use a fallback if the MAP_32BIT allocation fails.
I suspect they would be better off if they allocated the thread local data separately. The 2.4 kernel used to do the same, but switched to separate allocation because this gives better cache colouring (stacks tend to be aligned too much and use only parts of the cache)
MAP_32BIT only allocates in the first 2GB BTW, it's really MAP_31BIT.
-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/
| |