3 ms·

Asides from significant memory use from uncounted overhead for native threads, fun starts when your threads start actually using more than a single page of stac

by labawi 6y ago

Asides from significant memory use from uncounted overhead for native threads, fun starts when your threads start actually using more than a single page of stack, calling into who-knows-what, instead of just sleeping. Typical programs will transparently grow stack on demand, both with native threads (memory not mapped until used) and goroutines / green threads. Unlike green threads of typical runtimes, I don't know of native threading that releases no longer used stack space, until .. I guess the thread is destroyed, so sporadic large stack use on can blow up your memory.

masklinn 6y ago
> Unlike green threads of typical runtimes, I don't know of native threading that releases no longer used stack space, until .. I guess the thread is destroyed, so sporadic large stack use on can blow up your memory. They don't. Although if you know that may be a concern for your application you can easily enough `madvise` after calls which may map significant amounts of stack, in order to release it.
- labawi 6y ago
  While possible, sprinkling code with madvise syscalls to release memory doesn't seems like a very realistic proposition. Information on how much stack is actually mapped is not readily (or cheaply) available. The article says: > The workload is representative for measuring absolute memory overhead, but is not representative for time overhead. The workload is definitely not representative of real memory overhead. What's worse, it almost can be, but it is very dependent on the pattern of stack usage and it may not be obvious that you are holding on to large amounts of stack. Default stack size on linux is 8MB. If you don't use much stack, 10k threads might only need 200M of RAM. Or your threads might touch 2M of stack early in their lifetime, parsing recursive data structures or whatever, and you need 20G of RAM, because you're stacks don't get freed. Realistically, when using green threading, I wouldn't give much thought before using 10K waiting threads. With native threading, I would look for other reasonable solutions, because it's not worth the headaches, but in case they do turn out to be the most reasonable solution, I would be sure to appropriately lower the stack size to avoid OOM, budget at least a week for solving gotchas, and forever need to be vigilant about stack usage.

by labawi 6y ago

masklinn 6y ago

> Unlike green threads of typical runtimes, I don't know of native threading that releases no longer used stack space, until .. I guess the thread is destroyed, so sporadic large stack use on can blow up your memory. They don't. Although if you know that may be a concern for your application you can easily enough `madvise` after calls which may map significant amounts of stack, in order to release it.

labawi 6y ago
While possible, sprinkling code with madvise syscalls to release memory doesn't seems like a very realistic proposition. Information on how much stack is actually mapped is not readily (or cheaply) available. The article says: > The workload is representative for measuring absolute memory overhead, but is not representative for time overhead. The workload is definitely not representative of real memory overhead. What's worse, it almost can be, but it is very dependent on the pattern of stack usage and it may not be obvious that you are holding on to large amounts of stack. Default stack size on linux is 8MB. If you don't use much stack, 10k threads might only need 200M of RAM. Or your threads might touch 2M of stack early in their lifetime, parsing recursive data structures or whatever, and you need 20G of RAM, because you're stacks don't get freed. Realistically, when using green threading, I wouldn't give much thought before using 10K waiting threads. With native threading, I would look for other reasonable solutions, because it's not worth the headaches, but in case they do turn out to be the most reasonable solution, I would be sure to appropriately lower the stack size to avoid OOM, budget at least a week for solving gotchas, and forever need to be vigilant about stack usage.