[Beowulf] hang-up of HPC Challenge

[Peter St. John]

Brian,
Yes indeed, s/limited/unlimited/. I was thinking perhaps by "unlimited" they
meant allocating the stack from virtual memory, but anyway a source of
possible trouble.
Thanks
Peter

On 8/19/08, Brian Dobbins <bdobbins at gmail.com> wrote:
>
>
> On Tue, Aug 19, 2008 at 8:04 PM, Peter St. John <peter.st.john at gmail.com>wrote:
>
>> What I meant was: surely the stacksize is not really limited, even it it
>> is configured without limits?
>
>
>   If you meant to say *un*limited there, then yes, it's not really
> unlimited.  Someone with more kernel knowledge will certainly correct me if
> I'm wrong here, but I believe the stack is allocated 'upward' from the end
> of where your data/program reside in memory, whereas variables on the heap
> are (or tend to be, in fragmented memories) allocated 'downward' from the
> maximum available free memory.  So, at some point, those two will meet if
> you have limited ram, and your stack size most certainly won't be
> 'unlimited' at that point.
>
>  ... Bear in mind, my only experience with this is from the old 2.4 series
> kernels, where you had to modify how heap allocations were done in order to
> get above 2GB on 32-bit machines.  Given that that's ancient history, things
> may have changed.  ;)
>
>   (And, in more detail - if you set a limit, you get just that much... if
> you set 'unlimited', you get up until stack + heap allocations (+ data
> segments, OS stuff, etc.) run you out of memory.  Also, while heap
> allocations can be swapped out to virtual memory, I'm not too sure stack can
> be, as it tends to be faster, and used a bit differently.  Anyone know?)
>
>   Cheers,
>   - Brian
>
>
> Brian Dobbins
> Yale Engineering HPC
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.scyld.com/pipermail/beowulf/attachments/20080820/5b0bfdee/attachment.html