Archives


- Beowulf
- Beowulf Announce
- Scyld-users
- Beowulf on Debian

[Beowulf] hang-up of HPC Challenge

Many of your questions may have already been answered in earlier discussions or in the FAQ. The search results page will indicate current discussions as well as past list serves, articles, and papers.

Search

Perry E. Metzger perry at piermont.com
Wed Aug 20 09:13:44 PDT 2008


Mark Hahn <hahn at mcmaster.ca> writes:
>>> 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...

Or until it hits an internal limit of some sort.

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

That is architecture dependent, though I will admit that most common
modern architectures, such as the x86 descended ones, work that way.

> yeah, pretty much - text and heap are the same, but the mmap arena
> starts at ~182 GB instead of 1 GB.

That also depends. You can request mmaps at specific locations, and
different operating system variants pick different defaults when you
don't request one.

> the memory manager just knows pages; it doesn't really care whether
> the app thinks of it as stack or heap.

Again, not precisely true. Most modern operating systems don't
allocate stack pages in advance of use -- they have logic that knows
that a region is stack and automatically allocates a new stack page if
there is a fault caused by accessing the page past the top of the
stack.

-- 
Perry E. Metzger		perry at piermont.com



More information about the Beowulf mailing list