You can customize it but the default value for Linux is 2MB, the Go one is 2KB, pretty big difference in term of memory.

http://man7.org/linux/man-pages/man3/pthread_create.3.html

2KB is tiny, that must be a default which grows or is extended as required? Obviously it works out okay for them, but I feel like it would add nontrivial overhead to every function call if you're always having to check whether or not you need to grow your stack to accommodate the new frame.

Linux does not immediately map 2MB of stack for every thread. That would be ridiculous. Look in proc/smaps to see how much space your stacks actually occupy.

It's just a question of defaults. If stack size is your only concern, then change the default in your runtime: don't go M:N.

A deeper problem is with Linux threads you can’t grow the stack beyond whatever limit you choose, so you either have to write all code with very limited stack usage or set a big enough stack for the worst case. Which will be too big for millions of threads.

Stack growth should work in 1:1 just as it does in M:N. If the size were a hard constraint then Go couldn't get around it either.

That doesn’t appear to be true. The thing doing scheduling has to cooperate with the thing doing stack management, so that context can be switched.

What are those two things, in your proposition that we can simply use Linux threads?

The kernel has to restore registers, including the stack pointer, on a context switch. But it doesn't care about how big the allocation underpinning that stack is.