3 ms·

> but is it realistic to run 1M OS threads? It feels like the overhead per green thread is much lower What kind of overhead do OS thread have that green thread

by stymaar 10y ago

> but is it realistic to run 1M OS threads? It feels like the overhead per green thread is much lower What kind of overhead do OS thread have that green thread doesn't ? I'm aware of the stack size, but is there something else ? If the stack size is the only culprit here, what prevents the admin from manually setting a small stack size that will be enough for most operation (in practice, I don't know how useful the ability to grow dynamically the stack size in languages with green threads). > An OS thread may be paused while holding a (vm internal) lock, but the vm scheduler would not preempt a green thread in the middle of doing something that requires a lock (ex: Delivering a message to another green thread) That's an interesting point.

toast0 10y ago
> What kind of overhead do OS thread have that green thread doesn't ? I'm aware of the stack size, but is there something else ? Real context switches (with cache invalidation) to switch between, system call (with context switch to kernel) to create/dispose, probably kernel bits that will explode with huge thread lists: I wouldn't be surprised if listing all threads with ps or top also locks the thread lists: not a big deal if you have a reasonable number of threads, but could block thread creation in a 1M thread case.
- pcwalton 10y ago
  Context switches are really fast on modern x86.
  - Jweb_Guru 10y ago
    Plus there are specialized hardware instructions for them, and the expensive parts (saving weird registers etc.) are fast-pathed in Linux if they're not being used.
  - toast0 10y ago
    > Context switches are really fast on modern x86. Not context switching is even faster. How fast is really fast, how modern is modern? some results from 2010 [1] show at least 1000 nanoseconds per context switch (even with optimizations for the kernel switching between threads of the same process). That's not that slow, but it is a lot of time you could be doing something else. [1] http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-ma... [1] http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-ma...
slrz 10y ago
Besides the stack size there's also the switching overhead involved when you go through the kernel. And yes, the dynamic stack growth is an extremely important part of it. Without it, you'd just have small stacks. Take an arbitrary pthreads program and restrict its stacks to a few kb. You won't have much fun. The code really needs to be written such that it can cope with small stacks. That can be tedious, so you don't want to do it for run-of-the-mill userspace code. Dynamically-sized stacks give you the best of both worlds.
- pcwalton 10y ago
  You can use dynamically-sized stacks with pthreads. Nothing says you can't. Dynamically sized stacks are a property of GC, not userland threads. This is a common misconception.

by stymaar 10y ago

toast0 10y ago

> What kind of overhead do OS thread have that green thread doesn't ? I'm aware of the stack size, but is there something else ? Real context switches (with cache invalidation) to switch between, system call (with context switch to kernel) to create/dispose, probably kernel bits that will explode with huge thread lists: I wouldn't be surprised if listing all threads with ps or top also locks the thread lists: not a big deal if you have a reasonable number of threads, but could block thread creation in a 1M thread case.

pcwalton 10y ago
Context switches are really fast on modern x86.
- Jweb_Guru 10y ago
  Plus there are specialized hardware instructions for them, and the expensive parts (saving weird registers etc.) are fast-pathed in Linux if they're not being used.
- toast0 10y ago
  > Context switches are really fast on modern x86. Not context switching is even faster. How fast is really fast, how modern is modern? some results from 2010 [1] show at least 1000 nanoseconds per context switch (even with optimizations for the kernel switching between threads of the same process). That's not that slow, but it is a lot of time you could be doing something else. [1] http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-ma... [1] http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html http://blog.tsunanet.net/2010/11/how-long-does-it-take-to-ma...

slrz 10y ago

Besides the stack size there's also the switching overhead involved when you go through the kernel. And yes, the dynamic stack growth is an extremely important part of it. Without it, you'd just have small stacks. Take an arbitrary pthreads program and restrict its stacks to a few kb. You won't have much fun. The code really needs to be written such that it can cope with small stacks. That can be tedious, so you don't want to do it for run-of-the-mill userspace code. Dynamically-sized stacks give you the best of both worlds.

pcwalton 10y ago
You can use dynamically-sized stacks with pthreads. Nothing says you can't. Dynamically sized stacks are a property of GC, not userland threads. This is a common misconception.