4 ms·
Interesting, in my mind the memory usage of M threads is too expensive when you’re mostly waiting for network or file system events, the advantage I remember fr
by thepumpkin1979 8y ago
Interesting, in my mind the memory usage of M threads is too expensive when you’re mostly waiting for network or file system events, the advantage I remember from green threads is that the thread can be used to execute another CPU bound task while waiting for network events which intrinsically makes it more memory efficient. I’m interested in how Linux has evolved to reduce memory consumption when you have millions of threads, because you can have millions of green threads.
- pcwalton 8y agoMost of the memory usage comes from the user stack, and you can customize the size of the stack. So memory consumption isn't really the limiting factor here. More important is the cost of context switching.
- bboreham 8y agoA 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.
- pcwalton 8y agoStack 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.
- bboreham 8y agoThat 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?
- pcwalton 8y agoThe 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.
- Thaxll 8y agoYou 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 http://man7.org/linux/man-pages/man3/pthread_create.3.html
- pcwalton 8y agoIt'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.
- romed 8y agoLinux 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.
- mikepurvis 8y ago2KB 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.