Yes, and that’s fine. Linux scales quite well to tons of OS threads.
This Tweet was deleted by the Tweet author. Learn more
Conversation
This Tweet was deleted by the Tweet author. Learn more
This Tweet was deleted by the Tweet author. Learn more
Stack sizes and green thread/OS thread are orthogonal concerns. You could have OS threads with very small stacks too.
Small stacks are a property of GC, not of the threading model.
1
8
This Tweet was deleted by the Tweet author. Learn more
Yes, if you had a GC. The kernel stack size is 8kB, which is pretty small. Add 2kB for the userland size and you’re at 10kB.
I don’t think the difference between 2kB and 10kB per thread matters for most apps, which often have to grow that size anyway.
4
1
7
He's talking about the stacks for kernel threads, not userspace threads. As you bring up, there's also a pretty big difference between actual memory usage and a memory mapping without backing pages. The practical limit on number of threads on Linux is the arbitary max_map_count.
1
That can simply be massively raised and there have been proposals to do that by default or to remove it outright, which is probably going to happen in the next couple of years. Even without overcommit it's possible to reserve terabytes of virtual machine by starting as PROT_NONE.
1
Guard pages are just one approach to stack overflow detection and that's really completely orthogonal to 1:1 vs. M:N threading as is stack size. It makes sense to use guard pages with M:N threading, and you aren't forced to use that approach to detect overflow with 1:1 threading.