[Openmp-commits] [PATCH] D62488: Added propagation of not big initial stack size of master thread to workers.

Andrey Churbanov via Phabricator via Openmp-commits openmp-commits at lists.llvm.org
Fri May 31 08:08:20 PDT 2019

AndreyChurbanov marked 2 inline comments as done.
AndreyChurbanov added inline comments.

Comment at: runtime/src/z_Linux_util.cpp:1844
+    if (__kmp_stksize > KMP_DEFAULT_STKSIZE * 64) // just a heuristics...
+      __kmp_stksize = KMP_DEFAULT_STKSIZE;
+    __kmp_check_stksize(&__kmp_stksize); // check value just in case
jdoerfert wrote:
> I would have assumed we have a limit and we propagate `min(MASTER_STACK_SIZE, LIMIT_STACK_SIZE)` so if you are a bit over the "limit" you don't fall back to the potentially way lower default.
Not sure I got the question here. 

Couple more details anyway.  We've got request to propagate 8MB, because it was default limit on user's system and we had 4MB internal default in the library, that caused crash.  Then we can as well propagate 16MB, 20MB, etc.  But we cannot propagate 3GB because it slows down a lot of programs.  So we have to stop propagation at some stack size limit.  I haven't investigated what is the perfect value for upper bound we want to propagate. Would guess it can depend on a lot of factors...  So just (arbitrary) chosen 256MB (haven't seen slowdowns with this value), and "a bit over" means "do not propagate" for me.  Anyway we have standard external control, so if people need particular stack size for worker threads they can explicitly express that, same as set any stack size for master thread using system means and compiler/linker.

Comment at: runtime/test/misc_bugs/stack-propagate.c:62
+#endif // _WIN32
+  return 0;
jdoerfert wrote:
> Can you `return 1` on failure?
Sure, I will fix the test.



More information about the Openmp-commits mailing list