Re: [PATCH] sched: Further restrict the preemption modes

Valentin Schneider
2026-01-06T15:23:08Z

On 19/12/25 11:15, Peter Zijlstra wrote:
> [ with 6.18 being an LTS release, it might be a good time for this ]
>
> The introduction of PREEMPT_LAZY was for multiple reasons:
>
> - PREEMPT_RT suffered from over-scheduling, hurting performance compared to
> !PREEMPT_RT.
>
> - the introduction of (more) features that rely on preemption; like
> folio_zero_user() which can do large memset() without preemption checks.
>
> (Xen already had a horrible hack to deal with long running hypercalls)
>
> - the endless and uncontrolled sprinkling of cond_resched() -- mostly cargo
> cult or in response to poor to replicate workloads.
>
> By moving to a model that is fundamentally preemptable these things become
> manageable and avoid needing to introduce more horrible hacks.
>
> Since this is a requirement; limit PREEMPT_NONE to architectures that do not
> support preemption at all. Further limit PREEMPT_VOLUNTARY to those
> architectures that do not yet have PREEMPT_LAZY support (with the eventual goal
> to make this the empty set and completely remove voluntary preemption and
> cond_resched() -- notably VOLUNTARY is already limited to !ARCH_NO_PREEMPT.)
>
> This leaves up-to-date architectures (arm64, loongarch, powerpc, riscv, s390,
> x86) with only two preemption models: full and lazy (like PREEMPT_RT).
>
> While Lazy has been the recommended setting for a while, not all distributions
> have managed to make the switch yet. Force things along. Keep the patch minimal
> in case of hard to address regressions that might pop up.
>
> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>

Reviewed-by: Valentin Schneider <vschneid@redhat.com>