-
-
Notifications
You must be signed in to change notification settings - Fork 40
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(Lazy) Consider to use LAZY Preemption as default on desktop kernels #339
Comments
I have been tire 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. |
Rejoice lazy preemption lovers. The elapsed compile time benchmarks with dynamic preemption have converged and there is a performance boost (albeit small). Compiling mesa: 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 |
By observing a few results, it is observed that dynamic preemption can somehow blur the results between the various preemption models. One example is [1] where there seems to be a 5% difference in throughput between voluntary vs full with dynamic preemption disabled but then the difference goes to a measly 0.6% when dynamic preemption is enabled. I've also been able to reproduce this behaviour across various benchmarks, one of them shared in [2]. Due to that, let's disable dynamic preemption for all kernel configurations (or atleast the default) [1] https://lore.kernel.org/all/579b7ea34ef6e2f7c955abdfc0929fe1af36faef.camel@gmx.de/ [2] #339 Signed-off-by: Eric Naim <dnaim@cachyos.org>
With promising results shared in #339, let's enable this and see how it goes. Signed-off-by: Eric Naim <dnaim@cachyos.org>
By observing a few results, it is observed that dynamic preemption can somehow blur the results between the various preemption models. One example is [1] where there seems to be a 5% difference in throughput between voluntary vs full with dynamic preemption disabled but then the difference goes to a measly 0.6% when dynamic preemption is enabled. I've also been able to reproduce this behaviour across various benchmarks, one of them shared in [2]. Due to that, let's disable dynamic preemption for all kernel configurations (or atleast the default). Note that PREEMPT_DYNAMIC is kept enabled for fully preempted kernels, as it is observed that it doesn't seem to matter for those, so having more options is the priority in this case. [1] https://lore.kernel.org/all/579b7ea34ef6e2f7c955abdfc0929fe1af36faef.camel@gmx.de/ [2] #339 Signed-off-by: Eric Naim <dnaim@cachyos.org>
With promising results shared in #339, let's enable this and see how it goes. Signed-off-by: Eric Naim <dnaim@cachyos.org>
Lazy preemption fails quite hard in high load, see https://flightlesssomething.ambrosia.one/benchmark/950. |
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.
The text was updated successfully, but these errors were encountered: