3 ms·

> There is still a default stack size limit of 8 megabytes on Linux, even though consumer machines nowadays have RAM measured in double-digit gigabytes. Curren

> There is still a default stack size limit of 8 megabytes on Linux, even though consumer machines nowadays have RAM measured in double-digit gigabytes. Current stack sizes are fine; storing large amounts of information on the stack usually isn't a good idea anyway, and makes tools like debuggers and perf(1) slow and awkward. Besides, the ulimit means nothing. If you really want, you can allocate your own "stack", as large as you want, and switch to it. I just wouldn't recommend it. > A thread's stack cannot be temporarily extended; there may be something in the address space preventing it, since it's just another mmap. You might be interested in the split stack model, described here [1]. You definitely can grow a thread's stack as needed. The approach has various issues (which is why Rust eventually went with conventional stacks), but it certainly works. [1] https://gcc.gnu.org/wiki/SplitStacks https://gcc.gnu.org/wiki/SplitStacks

avar 9y ago
Current limits are fine, but also meaningless since you can trivially bypass them? If so why not raise the limits if they're only serving to have everyone implement their own bespoke stacks.
- quotemstr 9y ago
  The ulimit serves as a good reminder that excessive stack use is undesired.
  - avar 9y ago
    It's not a reminder if Linux's default configuration is to hard limit it at 32768, that means that if you need 32769 of stack you need to hack your own implementation for your program to be portable, or otherwise the user must be able to "sudo".
BeeOnRope 9y ago
How does big stacks slow down perf? I agree putting large amounts of data on the stack isn't a great idea, but I think it's mostly because (a) default stack sizes are quite small (b) they vary by distribution and even local configuration and (c) if you happen to be on any thread other than the main thread, it's the pthread stack size that matters and this is even usually smaller than the default main thread stack. I never heard of it causing any problems for perf. Yes, perf unwinds the stack if you ask it to, but all the mechanisms will don't depend (AFAIK) on the stack size.
- kazinator 9y ago
  By the way, on glibc/Linux, you need (main thread) stack space proportional to the complexity of your shared libraries (number of symbols). The ld.so memory manager uses alloca for data structures related to symbol resolution.
  - BeeOnRope 9y ago
    Interesting. I guess this memory is also used at somewhat unpredictable times in the usual case where symbols are resolved lazily though the PLT: when you first use a function you'll suddenly get this extra stack usage while ld.so does it's thing? Doesn't that also imply this caveat also applies to thread stacks if you end up resolving symbols off of the main thread?
- gnufx 9y ago
  Putting large data on the stack is a good idea as a standard Fortran optimization, at least (gfortran -fstack-arrays and ifort default, I think). You typically need to increase the stack limit greatly for HPC jobs. I'm not aware of that causing trouble for profiling, and would also be interested in how it does.

avar 9y ago

Current limits are fine, but also meaningless since you can trivially bypass them? If so why not raise the limits if they're only serving to have everyone implement their own bespoke stacks.

quotemstr 9y ago
The ulimit serves as a good reminder that excessive stack use is undesired.
- avar 9y ago
  It's not a reminder if Linux's default configuration is to hard limit it at 32768, that means that if you need 32769 of stack you need to hack your own implementation for your program to be portable, or otherwise the user must be able to "sudo".

BeeOnRope 9y ago

How does big stacks slow down perf? I agree putting large amounts of data on the stack isn't a great idea, but I think it's mostly because (a) default stack sizes are quite small (b) they vary by distribution and even local configuration and (c) if you happen to be on any thread other than the main thread, it's the pthread stack size that matters and this is even usually smaller than the default main thread stack. I never heard of it causing any problems for perf. Yes, perf unwinds the stack if you ask it to, but all the mechanisms will don't depend (AFAIK) on the stack size.

kazinator 9y ago
By the way, on glibc/Linux, you need (main thread) stack space proportional to the complexity of your shared libraries (number of symbols). The ld.so memory manager uses alloca for data structures related to symbol resolution.
- BeeOnRope 9y ago
  Interesting. I guess this memory is also used at somewhat unpredictable times in the usual case where symbols are resolved lazily though the PLT: when you first use a function you'll suddenly get this extra stack usage while ld.so does it's thing? Doesn't that also imply this caveat also applies to thread stacks if you end up resolving symbols off of the main thread?
gnufx 9y ago
Putting large data on the stack is a good idea as a standard Fortran optimization, at least (gfortran -fstack-arrays and ifort default, I think). You typically need to increase the stack limit greatly for HPC jobs. I'm not aware of that causing trouble for profiling, and would also be interested in how it does.