[PATCH] Dynamic thread stack size

Julian Elischer julian at elischer.org
Mon Jan 24 16:39:46 PST 2005



Joe Marcus Clarke wrote:

>On Mon, 2005-01-24 at 15:15 -0800, Julian Elischer wrote:
>  
>
>>Joe Marcus Clarke wrote:
>>
>>    
>>
>>>On Mon, 2005-01-24 at 14:31 -0500, Daniel Eischen wrote:
>>> 
>>>
>>>      
>>>
>>>>On Mon, 24 Jan 2005, Joe Marcus Clarke wrote:
>>>>
>>>>   
>>>>
>>>>        
>>>>
>>>>>On Sat, 2005-01-22 at 13:03 -0500, Daniel Eischen wrote:
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>>>On Fri, 21 Jan 2005, Joe Marcus Clarke wrote:
>>>>>>
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>>>In a follow-up to the previous discussion on increasing our default
>>>>>>>thread stacksize, I thought I'd look at how some other BSD
>>>>>>>implementations do it.  Mezz mentioned that he thought NetBSD had a 2 MB
>>>>>>>default stacksize, so I took a look.
>>>>>>>
>>>>>>>What I found was that NetBSD doesn't have a static default stacksize.
>>>>>>>Instead, they use the stacksize rlimit and a PTHREAD_STACKSIZE
>>>>>>>environment variable to get both the initial stacksize as well as each
>>>>>>>thread's default stacksize.  I thought this would be a really good way
>>>>>>>of doing things, so I ported their work to FreeBSD.
>>>>>>>         
>>>>>>>
>>>>>>>              
>>>>>>>
>>>>>>Please no.  I don't want to have to set any more environment
>>>>>>variables or login defaults to get libpthread to work with
>>>>>>certain ports.
>>>>>>       
>>>>>>
>>>>>>            
>>>>>>
>>>>>No need.  The default stacksize rlimit is more than enough (64 MB) to
>>>>>satisfy every one of the affected ports thus far.  The environment
>>>>>     
>>>>>
>>>>>          
>>>>>
>>>>And 64MB is way too big for a default stack size...
>>>>   
>>>>
>>>>        
>>>>
>>>Okay, so lobby that it gets reduced in login.conf.  Why should threads
>>>be given less stack than processes, especially the initial thread?
>>>
>>>      
>>>
>>because there may be 50 of them? (or maybe even 500?)
>>
>>Threaded programs are supposed to be aware that stack is a limited resource.
>>    
>>
>
>I thought about that, but I also thought that KSEs were treated
>similarly to processes so it wouldn't matter if each one had a full
>allocation of stacksize?
>

we're talking about he stacksize in userland.. and every thread has to 
have a separae one,
and they have to all fit in the same address space..

64 MB is what, 16 threads per GB of addresss space?
if you take into account that there a re grat chunks of address space 
not available,
then you really would be limiting yourself to about 32 threads..

It doesn't take a lot of imagination to see people using more than 32 
threads.

>
>Joe
>
>  
>
>>    
>>
>>>Joe
>>>
>>> 
>>>
>>>      
>>>
>>    
>>



More information about the freebsd-threads mailing list