4 ms·
Seems like a moot point on any 64 bit platform, where you can effectively reserve GBytes of virtual memory for each of thousands of threads, and page in physica
by yholio 5y ago
Seems like a moot point on any 64 bit platform, where you can effectively reserve GBytes of virtual memory for each of thousands of threads, and page in physical memory as required.
It's the only sane interpretation I can give to a standard that hides any way to manage stack usage - the compiler/OS layer takes responsibility.
- noobermin 5y agoIf it's the OS's responsibility then Alpine Linux shouldn't blame developers or say their code isn't "portable."
- aidenn0 5y agoGigabytes for thousands of threads is just barely true; if you reserved say 8GB each for 16k threads, you would just about use up the 47 bits of address space reserved for userland on Linux leaving nothing for text or heap. Certainly a few MB per thread isn't too crazy though; at 8MB per thread, you can have a million threads and use only a tiny fraction of the address space available.
- yholio 5y agoYou could reserve, say, 46 bits for heap and 46 for stack, 70 terabytes each ought to be enough for anybody. Then start allocating thread stack in successive halvings: 2 threads get 35TB each, 65536 threads get 1GB each etc. Effectively, you can make sure the program runs out of available memory long before a stack exhaustion issue, unless the stack usage pattern is severely unbalanced for some thread.
- jart 5y agoVirtual memory isn't free. 16k threads with 8gb stacks technically needs like 250gb of page tables. You must be using some strange memory model and microprocessor that lets you have 92 bits of address space.
- aidenn0 5y ago1. 2^46 + 2^46 is 2^47 2. The actual size of the page-table will depend on the page sizes supported by the architecture. On modern x86_64 for programs with less than 32k threads, It might make sense to use 1GB stacks with 1GB guard pages, for just 2 PTEs per thread, less than the 5 needed for 8MB using 2MB pages.