Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 12 Nov 98 14:26:22 -0600
From:      "Richard Seaman, Jr." <lists@tar.com>
To:        "green@unixhelp.org" <green@unixhelp.org>, "Luoqi Chen" <luoqi@watermarkgroup.com>
Cc:        "current@FreeBSD.ORG" <current@FreeBSD.ORG>
Subject:   Re: RFSIGSHARE ready?
Message-ID:  <199811122026.OAA17559@ns.tar.com>

next in thread | raw e-mail | index | archive | help
On Thu, 12 Nov 1998 14:17:43 -0500 (EST), Luoqi Chen wrote:

>> 2) linux threads creates stacks for each thread it creates via
>> mmap.  It decides on where to start allocating them using the
>> following algorithm (I think). 
>> 
>> 	It gets the stack pointer of the initial thread, 
>> 	figures the initial thread can get by with 2*STACK_SIZE
>> 	bytes (4MB in this case), and then starts allocating
>> 	thread user stacks 2*STACK_SIZE below the initial
>> 	thread stack.
>> 
>> I don't pretend to really understand FreeBSD vm, to the following
>> is just a guess on my part.  Maybe someone else can shed more
>> light on this.
>> 
>> The problem is that FreeBSD dedicates 64MB for a process stack
>> (ie. for the initial thread), so that linux threads starts out
>> mmaping into the initial thread stack region.  I don't know 
>> exactly what happens at that point, but it doesn't seem to
>> be good. 
>> 
>I don't see anything bad, if the initial thread doesn't use more than
>2*STACK_SIZE.
>
>> I'm not sure why FreeBSD mmap allows a mmap into the process
>> user stack to succeed (but it appears to).  
>> 
>Why not? The only difference user stack from other user memory is
>the kernel imposes an autogrow policy.
>
>> You could consider patching either linux_mmap or the FreeBSD
>> mmap to reject attempts to mmap at virtual addresses above
>> p->p->vmspace->vm_maxaddr.  I haven't tried this, so I don't
>> know if it will work.
>> 
>> What this would do to an unmodified linux threads implementation
>> would be (I think) that the first 31 or 32 stack addresses it
>> tries to create would fail since they are trying to map into
>> the initial thread stack.  But, after that, mmaps should succeed
>> and maybe the addresses will be ok.  You'd loose the ability to
>> create 31 or 32 threads out of the total 1024 that linux threads
>> allows, but that wouldn't be the end of the world.
>> 
>The first 31 threads are fine, in fact, they will enjoy the benefit
>of the autogrow policy on the user stack.

Well, you no doubt are right.  I only said what I did because I've
tried running linux threads in FreeBSD "native".  Granted, the
signal handling wasn't quite right, and maybe that was and still
is the problem I experienced.

But, my experience was that my test app would hang during the
creation of the first thread *unless* I *both* increased
the stack size to a non-zero value *and* moved it out of the
process stack area.  That's why I said it didn't seem to be
a good idea to put zero size (or larger) thread stacks into
the process stack area.

I'll try it all again when the signal handling is fixed.



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811122026.OAA17559>