Two-level (M:N) scheduling multiplexes many user-level threads over a smaller set of kernel-scheduled threads. What does it buy, and why did several mature operating systems abandon their M:N implementations in favour of one-to-one kernel threading?

## What M:N is In a two-level model the program creates M user-level threads; the runtime schedules them onto N kernel-scheduled host threads, with N typically near the number of cores. Each host runs a small dispatch loop: pick a ready user thread, restore its continuation, run it until it blocks or yields, save it, pick another. Work-stealing between per-host run queues keeps the cores busy. The goal is to have both halves of the tradeoff at once: from N:1, cheap creation, tiny growable stacks and nanosecond switches; from 1:1, execution on all cores and tolerance of a thread that blocks. ## What it buys - **Thread count decoupled from kernel resources.** Hundreds of thousands of user threads over a handful of hosts, because the kernel only accounts for the hosts. - **Parallelism.** Unlike N:1, several hosts can be on several cores simultaneously. - **A programming model people can actually reason about.** Sequential, blocking-looking code with straightforward stack traces, rather than callbacks or a hand-rolled state machine — while the runtime quietly turns each block into a park. - **Locality control.** The runtime can keep a user thread on the host that last ran it, or steal deliberately, in ways the kernel cannot because it lacks application knowledge. ## The central difficulty: blocking system calls Everything rests on being able to unmount a user thread when it is about to wait. If the wait happens *inside the kernel* — a synchronous read, a page fault, a native library that blocks on its own — the host thread is gone from service for the duration, and the user scheduler is not executing to do anything about it. With N hosts and N such calls in flight, the program is stopped even though thousands of user threads are ready. Two families of fixes exist: 1. **Interception.** The runtime replaces every blocking operation with a non-blocking equivalent plus a park: register with an event notifier, save the continuation, run something else, resume on completion. This works only if the runtime controls the entire blocking surface — its own I/O library, its own locks, its own sleeps. 2. **Kernel cooperation — scheduler activations.** The kernel notifies the runtime by upcall when a host blocks and hands it a fresh execution context, then notifies it again when the original unblocks. This was the classic research answer and it does work, but it requires a kernel interface, careful handling of nested upcalls, and considerable subtlety around signals and preemption. ## The rest of the friction - **Signals.** POSIX signals are delivered to kernel threads. Which user thread should see a signal that arrives while its host is running someone else? Getting this right across all the corner cases is notoriously delicate. - **Priorities and inversion.** The kernel prioritises hosts; the runtime prioritises user threads. A low-priority user thread holding a lock can block a high-priority one with no way for either scheduler to see the dependency, and classic remedies like priority inheritance do not span the two levels. - **Locks held across a park.** If a user thread parks while holding a lock the *kernel* knows about, the host that resumes it may be a different one — and constructs that record ownership by kernel-thread identity are now wrong. - **Per-thread OS state.** CPU affinity, scheduling class, CPU time accounting, resource limits, and native thread-local storage all attach to the host, not to the user thread that happens to be mounted on it. - **Tooling.** Debuggers, profilers, core dumps, and OS-level thread lists show hosts. Without deliberate runtime support, a stack trace shows the dispatcher rather than the application's logical thread, and a CPU profile attributes time to the wrong unit. - **Preemption.** A user thread that never yields — a tight compute loop — occupies its host until the runtime can interrupt it, which requires injected yield points or signal-based preemption. ## Why systems reverted to 1:1 During the 1990s and early 2000s, several Unix-family systems shipped two-level thread implementations and then replaced them with straightforward one-to-one kernel threading. The drivers were consistent: kernel thread creation and context switching got dramatically cheaper, so the performance gap narrowed; the correctness surface of the two-level design — signals, blocking, priorities, debugging — stayed expensive to maintain; and application demand at the time rarely exceeded a few thousand threads. Simplicity won on total cost, not on raw benchmark numbers. ## Why it came back The modern revival lives in *language runtimes* rather than in C threading libraries, and that distinction is the whole answer. A runtime that provides the I/O library, the lock implementations, the sleep primitives and the stack layout can guarantee that virtually every blocking operation yields, can capture continuations precisely, and can render its own stack traces and profiles. It does not need scheduler activations, because it never lets the block reach the kernel unmediated. Where it *cannot* mediate — native calls, some filesystem operations — the old failure mode returns as host pinning, which is exactly the residue of the classic problem. The interview-grade summary: M:N is the right model when one component owns the blocking surface, and the wrong model when blocking can arrive from anywhere.