Hi Christian.
Is this sent as a patch or just a reply to the thread?
If it is sent as patch, Please follow these guidelines.
https://docs.kernel.org/process/submitting-patches.html
On 2/25/26 11:24 AM, Christian Zigotzky wrote:
Hello,
We were previously able to disable PREEMPT in the kernel configuration,
but the latest kernels now enable it by default and it is no longer
possible to disable it.
Is it possible to let us decide whether to activate PREEMPT or not?
Currently we use the following revert patch for our non-preempt kernels.
--- a/kernel/Kconfig.preempt 2026-02-14 10:06:32.000000000 +0000
+++ b/kernel/Kconfig.preempt 2026-02-08 21:03:27.000000000 +0000
@@ -16,13 +16,11 @@ config ARCH_HAS_PREEMPT_LAZY
choice
prompt "Preemption Model"
- default PREEMPT_LAZY if ARCH_HAS_PREEMPT_LAZY
default PREEMPT_NONE
config PREEMPT_NONE
bool "No Forced Preemption (Server)"
depends on !PREEMPT_RT
- depends on ARCH_NO_PREEMPT
select PREEMPT_NONE_BUILD if !PREEMPT_DYNAMIC
help
This is the traditional Linux preemption model, geared towards
@@ -37,7 +35,6 @@ config PREEMPT_NONE
config PREEMPT_VOLUNTARY
bool "Voluntary Kernel Preemption (Desktop)"
- depends on !ARCH_HAS_PREEMPT_LAZY
depends on !ARCH_NO_PREEMPT
depends on !PREEMPT_RT
select PREEMPT_VOLUNTARY_BUILD if !PREEMPT_DYNAMIC
I would instead fix any issue we have in PREEMPT FULL/LAZY rather than falling
back to
old methods.
btw, did the previous patch sent, which you said helps you to boot, can you
confirm
it did help you? If yes, i can send it as patch, since cond_resched if called
from boot cpu
might be stuck in the loop forever.
IIRC, after boot, you had some driver causing crash. If so, share backtrace of
the crash?
If you don't use that driver, is the guest stable?
