(Lazy) Consider to use LAZY Preemption as default on desktop kernels

[ptr1337]

Lazy Preemption has been recently added to the 6.13 Kernel.
https://lwn.net/Articles/994322/

Generally, Lazy should replace "None" and "Voluntary", while maintaining for RT tasks still the full preemption modell.
We could adjust games in the future to use real time ISO, which allows to use at these full preemption, while other tasks still benefits from using the higher throughput.

Production Benchmarks generally looking good with Lazy Preemption.
Gaming needs to be evaluated.

[1Naim]

I have been tirelessly trying to benchmark this. Here are my latest benchmarks of full vs lazy with unixbench. Apart from the consistent regression in FIO across numerous runs, it's basically a cointoss between the two preemption models. This has also been observed in some elapsed compilations I made between full vs lazy (PREEMPT_DYNAMIC enabled in both kernels)

Mike's results from LKML also show that there's not much difference if at all between full vs lazy. I notice how the results between preemption models get tighter when dynamic preemption is enabled, so maybe we should do these benchmarks with it disabled. On the bright side, lazy preemption shows good results with PREEMPT_RT so maybe we can have that enabled to regain the huge performance loss that comes with realtime preemption.

TL;DR we should probably just keep full. I'm going to redo the compilation tests with the kernels here. They're both built with dynamic preemption disabled.

[1Naim]

Rejoice lazy preemption lovers. The elapsed compile time benchmarks with dynamic preemption have converged and there is a performance boost (albeit small).

Compiling mesa:
full: 424.69 423.83 424.81 - avg: 424.44 (sec)
lazy: 422.51 422.73 422.72 - avg: 422.65 (sec)

Improvements might be larger in micro-benchmarks.

---

For reference on how dynamic preemption can skewer results, here are results from a month ago with 2 different kernels with dynamic preemption enabled
full: 439.92 442.13 444.56
lazy: 443.08 443.41 443.11

[1Naim]

Lazy preemption fails quite hard in high load, see https://flightlesssomething.ambrosia.one/benchmark/950.

[1Naim]

For reference on how dynamic preemption can skewer results

Finally realized what happened here. RCUs aren't preemptible with dynamic preemption off. PREEMPT_RCU would always be disabled even if I try to explicitly enable it.

Lazy preemption fails quite hard in high load, see https://flightlesssomething.ambrosia.one/benchmark/950.

What's happening here is also likely because of PREEMPT_RCU being disabled. Maybe PREEMPT_DYNAMIC isn't broken after all.

[fridrichgood]

For reference on how dynamic preemption can skewer results

Finally realized what happened here. RCUs aren't preemptible with dynamic preemption off. PREEMPT_RCU would always be disabled even if I try to explicitly enable it.

Lazy preemption fails quite hard in high load, see https://flightlesssomething.ambrosia.one/benchmark/950.

What's happening here is also likely because of PREEMPT_RCU being disabled. Maybe PREEMPT_DYNAMIC isn't broken after all.

I started looking for information based on your observations and found a series of patches. In my free time, I will check if they are in the current kernel. I'm using a modified 6.13.3-zen now.

https://lwn.net/ml/all/[email protected]/

[1Naim]

Those patches are submitted for 6.15. If you can provide some of your observations too regarding full vs lazy, that would be nice :)