Linux preemption models

Preemption is the scheduler's decision about when it's allowed to interrupt a running thread and hand the CPU to another. Different workloads want different answers, so the Linux kernel exposes the choice as a build-time configuration.

The three models

PREEMPT_NONE — the kernel almost never interrupts a running thread. It runs until it gives up the CPU itself: a syscall, blocking I/O, an explicit sleep. Few context switches, high throughput, predictable behavior under load. Traditional server default.

PREEMPT_FULL — the kernel can interrupt a running thread at almost any safe point, including inside the kernel itself. Lower latency, more context-switch overhead. Traditional desktop default, where responsiveness wins over throughput.

PREEMPT_LAZY — introduced in Linux 6.12 as a compromise. Preemption is allowed but the scheduler tries to wait for natural boundaries before cutting in. Designed as a drop-in replacement for PREEMPT_NONE on throughput workloads.

What changed in Linux 7.0

Linux 7.0 removed PREEMPT_NONE on modern CPU architectures, leaving PREEMPT_FULL and PREEMPT_LAZY. Most server distros shifted their default to PREEMPT_LAZY. The transition is invisible for most software. But where it isn't, it really isn't — see linux-7-postgres-regression for a workload (PostgreSQL on a 96-vCPU box) where the change cut throughput in half because the scheduler can now preempt a thread that's holding a spinlock and is mid–page fault.

Why "drop-in" isn't drop-in

PREEMPT_NONE was a free implicit guarantee for any code holding a spinlock: even if the holder did something the kernel had to handle (a fault, a slow path), it wouldn't get descheduled until it was done. Code written before PREEMPT_LAZY could quietly rely on that. Once removed, every "the holder will be gone in nanoseconds" assumption needs to actually be true — or be backed by something stronger like restartable sequences.

What happens before any of this matters

The preemption model only takes effect after boot. During Phase 4 of linux-kernel-startup (start_kernel), interrupts are disabled for almost the entire run and the scheduler exists but isn't load-balancing yet. Real multitasking — the world where preemption decisions actually matter — starts in Phase 6 with sched_init_smp(). See linux-boot-phases for the broader ordering.