<div dir="ltr"><br><div class="gmail_quote">On Tue, Aug 19, 2008 at 8:04 PM, Peter St. John <span dir="ltr"><<a href="mailto:peter.st.john@gmail.com">peter.st.john@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
What I meant was: surely the stacksize is not really limited, even it it is configured without limits?</blockquote><div><br>  If you meant to say <i>un</i>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.<br>
<br> ... 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.  ;)<br>
<br>  (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?)<br>
<br>  Cheers,<br>  - Brian<br><br><br>Brian Dobbins<br>Yale Engineering HPC<br></div></div><br></div>