I believe the article fails to account for, among other things, the virtual memory overhead that comes with sparse allocations for large maximum stack sizes, that would about double the numbers. With 2MB or so stack spacing, if you only use a single page of RAM per thread, you still need another whole page of RAM in the "page table" (actually a trie) and on linux those are not counted in the process RES memory usage.
That being said, creating thousands of native threads has lots of other pitfalls, including stack ones - would not recommend as a general strategy.
If haven't tried creating actual threads, but for test mapping stack-like staggered memory, I've had success with:
sysctl vm.overcommit_memory=1
sysctl vm.max_map_count=10000000
swapoff -a
Remember to keep an eye on free memory, not process RES or similar, that doesn't count page tables and other overhead.
Note that page tables are the per-process virtual memory mapping data structure for the CPU. AFAICT, Linux has separate accounting of the memory, which is smaller, but also per-thread structures, which are likely not included in RSS either.
I believe the article fails to account for, among other things, the virtual memory overhead that comes with sparse allocations for large maximum stack sizes, that would about double the numbers. With 2MB or so stack spacing, if you only use a single page of RAM per thread, you still need another whole page of RAM in the "page table" (actually a trie) and on linux those are not counted in the process RES memory usage.
That being said, creating thousands of native threads has lots of other pitfalls, including stack ones - would not recommend as a general strategy.
If haven't tried creating actual threads, but for test mapping stack-like staggered memory, I've had success with:
Remember to keep an eye on free memory, not process RES or similar, that doesn't count page tables and other overhead.[1] https://news.ycombinator.com/item?id=25997506