On 03/30/2013 06:36 AM, Duke Nguyen wrote:
> On 3/30/13 5:22 PM, Duke Nguyen wrote:
>> On 3/30/13 3:13 PM, Patrick Bégou wrote:
>>> I do not know about your code but:
>>> 1) did you check stack limitations ? Typically intel fortran codes
>>> needs large amount of stack when the problem size increase.
>>> Check ulimit -a
>> First time I heard of stack limitations. Anyway, ulimit -a gives
>> $ ulimit -a
>> core file size (blocks, -c) 0
>> data seg size (kbytes, -d) unlimited
>> scheduling priority (-e) 0
>> file size (blocks, -f) unlimited
>> pending signals (-i) 127368
>> max locked memory (kbytes, -l) unlimited
>> max memory size (kbytes, -m) unlimited
>> open files (-n) 1024
>> pipe size (512 bytes, -p) 8
>> POSIX message queues (bytes, -q) 819200
>> real-time priority (-r) 0
>> stack size (kbytes, -s) 10240
>> cpu time (seconds, -t) unlimited
>> max user processes (-u) 1024
>> virtual memory (kbytes, -v) unlimited
>> file locks (-x) unlimited
>> So stack size is 10MB??? Does this one create problem? How do I
>> change this?
> I did $ ulimit -s unlimited to have stack size to be unlimited, and
> the job ran fine!!! So it looks like stack limit is the problem.
> Questions are:
> * how do I set this automatically (and permanently)?
> * should I set all other ulimits to be unlimited?
In our environment, the only solution we found is to have mpirun run a
script on each node which sets ulimit (as well as environment variables
which are more convenient to set there than in the mpirun), before
starting the executable. We had expert recommendations against this but
no other working solution. It seems unlikely that you would want to
remove any limits which work at default.
Stack size unlimited in reality is not unlimited; it may be limited by a
system limit or implementation. As we run up to 120 threads per rank
and many applications have threadprivate data regions, ability to run
without considering stack limit is the exception rather than the rule.