Re: [Linux PPC] Disable PREEMPT

Hi Michal.

On 9/3/26 3:23 PM, Michal Suchánek wrote:

On Thu, Feb 26, 2026 at 02:24:50PM +0100, Christophe Leroy (CS GROUP) wrote:

quoted

Hi Christian,

Le 26/02/2026 à 06:37, Christian Zigotzky a écrit :

quoted

On 25/02/26 08:16, Christophe Leroy (CS GROUP) wrote:

quoted

+Peter

Hi Christian,

Le 25/02/2026 à 06:54, Christian Zigotzky a écrit :

quoted

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?

Can you give more details on why you want to be able to deactivate
PREEMPT ?

Read https://eur01.safelinks.protection.outlook.com/? url=https%3A%2F%2Fgithub.com%2Ftorvalds%2Flinux%2Fcommit%2F7dadeaa6e851e&data=05%7C02%7Cchristophe.leroy2%40cs-soprasteria.com%7C7006c8b4b98c4315a7e508de74f9388a%7C8b87af7d86474dc78df45f69a2011bb5%7C0%7C0%7C639076810956939768%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=6xLB%2FOVSkmgZRamaBM9zaxm%2FUTk9ssf4409QJdiXkDg%3D&reserved=0

I use PREEMPT_NONE kernels on my Linux PPC servers. (Without desktop)

You are doing that today because it is possible. Tomorrow it will not be
possible anymore, for the reasons explained by Peter.

My question was not to know what you are doing but why, and why you think
you still need PREEMPT_NONE and why the modern PREEMPT_LAZY is not good
enough for you.

Hello,

I tried to compile a kernel with preemption for pSeries, and while
PREEMPT_VOLUNTARY works for me PREEMPT_LAZY crashes.

The kernel crashing is certainly a reason why a preemtion model would
not be good enough for me.

Is it the same issue that you said the bug which was discussed internally?
i.e around kvmhv_run_single_vcpu ? or is it different one?

This is not the latest kernel so it might have been fixed in the
meantime for the platform in question. Will need to check that.

If possible run against current upstream and share the results.

Nonethless, there are quite a few platforms. Originally no preemption
was the only option, and that's the reason why many people run that.
It's the conservative, known working option. And that's the reason a lot
of platfrom code does not get tested with more aggressive preemtion
models, and never gets fixed to work with them.

Full preemption has been there for many years!.
Lazy is not that aggressive compared to that.

Simply disabling the no preemtion option does not make the platform code
ready.

Let's understand your crash case. Let's see where it is going wrong. I am suspecting
it is some wrong usage of preemption api rather than arch can't support preemption.

Thanks

Michal

quoted

Christophe

quoted

quoted

quoted

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

---

Thanks in advance,

Christian