[Beowulf] hang-up of HPC Challenge

Mark Hahn hahn at mcmaster.ca
Tue Aug 19 21:46:08 PDT 2008

>> What I meant was: surely the stacksize is not really limited, even it it is
>> configured without limits?

unlimited just means that the kernel code responsible for letting 
the stack grow will not impose a specific limit until it "runs into"
some other memory allocation...

> 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

the opposite, actually.  stack is high and grows toward low addresses.
heap grows up from end of text; the mmap arena (which includes shared 
libraries) also grows upward.

> ... 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.  ;)

yeah, pretty much - text and heap are the same, but the mmap arena
starts at ~182 GB instead of 1 GB.  stack starts at (1<<64)-1, so is not
going to collide any time soon...

> 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?)

the memory manager just knows pages; it doesn't really care whether 
the app thinks of it as stack or heap.  (there are properties like 
page protection, backing store or grow-down allocation policy...)

regards, mark hahn.

More information about the Beowulf mailing list