This is a multipart MIME message.

--==_Exmh_3703195871780
Content-Type: text/plain; charset=us-ascii


Investigating why programs linked against the new libpthread
suffer from stack shortage I stumbled on the fact that
the user stack is initialized to
[some well aligned address imposed by pmap] - USPACE
Since the uareas are mapped to variable addresses in the
not-so-new-anymore pmap this looks like a waste for me.

libpthread's way of looking up thread private data
relies on aligned stack ranges. This causes the main
thread's stack's lower limit set to
[initial stack] & 0xfffc0000 (+ 8k)
Consequently, without subtracting USPACE we have a net
gain of 16k stack space with a default (ie with redzone)
kernel.

This certainly is not sufficient for stack intensive
applications, but otoh its 16k for free...

I'm running a kernel with the appended patch applied now,
and didn't find problems so far.
Or am I missing something?

best regards
Matthias



--==_Exmh_3703195871780
Content-Type: text/plain ; name="vmpatch.txt"; charset=us-ascii
Content-Description: vmpatch.txt
Content-Disposition: attachment; filename="vmpatch.txt"

Index: sys/arch/i386/include/vmparam.h
===================================================================
RCS file: /cvsroot/src/sys/arch/i386/include/vmparam.h,v
retrieving revision 1.46
diff -u -r1.46 vmparam.h
--- sys/arch/i386/include/vmparam.h	2002/12/10 05:14:28	1.46
+++ sys/arch/i386/include/vmparam.h	2003/01/21 13:19:40
@@ -101,7 +101,7 @@
 /* user/kernel map constants */
 #define VM_MIN_ADDRESS		((vaddr_t)0)
 #define	VM_MAXUSER_ADDRESS	\
-			((vaddr_t)((PDSLOT_PTE << PDSHIFT) - (UPAGES * NBPG)))
+			((vaddr_t)(PDSLOT_PTE << PDSHIFT))
 #define	VM_MAX_ADDRESS		\
 		((vaddr_t)((PDSLOT_PTE << PDSHIFT) + (PDSLOT_PTE << PGSHIFT)))
 #define	VM_MIN_KERNEL_ADDRESS	((vaddr_t)(PDSLOT_KERN << PDSHIFT))

--==_Exmh_3703195871780--