Runtime Analysis of the M-to-N Schedulling Model (1996) [pdf]

>By introducing a second layer of scheduling, the M-to-N model makes performance tuning to the model exceedingly difficult.

Reminds me of Simon Marlow's work[1] on tuning the Haskell runtime for a specific use at fb.

[1] https://simonmar.github.io/posts/2016-12-08-Haskell-in-the-d...

You still see M-N models in many software systems but they are used almost exclusively to keep one flavor of work from hogging resources.

Everyone else gets one share of the processor and the executor/task/job pool splits M shares among N tasks or queues up all but the first M, or combines elements of both strategies.

Go uses the M-to-N model for it's goroutines.

Yes, I am actually curious to hear Brian's take on Go's runtime, given its rather impressive performance characteristics. Brian is also bearish on segmented stacks.