There are several issues with this analysis. At the core is the implicit assumption that programming with lightweight threads looks the same as programming with

There are several issues with this analysis. At the core is the implicit assumption that programming with lightweight threads looks the same as programming with heavyweight threads. But the goal of lightweight threading is to allow the use of a software unit of concurrency (thread) to easily map to a domain unit of concurrency (session, request, transaction, service call etc.): 1. When programming with lightweight threads we want thread creation to be very, very cheap; pretty much as cheap as a context switch, because many concurrency units are transient (e.g. every incoming request can result in hundreds of outgoing concurrent service requests). 2. When programming with lightweight threads, it is very much possible that many of them would work significantly less than 1-5us between blocking. 3. When programming with lightweight threads you have hundreds of thousands or millions of concurrently active threads. Kernel scheduling overhead should be measured under those conditions, not with only 2 threads. 4. Finally, when relying on virtual memory, the smallest unit is the page. But when working with potentially millions of lightweight threads, many of those would have stacks smaller even than 1K. This is not to say that kernels will not be able to make their threads sufficiently lightweight in the future to enable a lightweight-concurrency programming style, but for now, they don't seem competitive with language-runtime implementations.