Thanks. Per OpenWrt PR, “CONFIG_PREEMPT=y” is causing worse performance. I think CONFIG_PREEMPT_VOLUNTARY would improve the performance for desktop usage only (not for minimal images with CLI only).
I just did a custom Armbian minimal test build (first time I build it myself) with the option “No Forced Preemption (Server)” as follows:
Update: I did a custom Armbian build with kernel configured with “No Forced Preemption (Server)” (per above, details below) and unfortunately it did not reduced the idle temperature. The quest continues…
root@r5s:~# uname -a
Linux r5s.home 6.12.9-current-rockchip64 #1 SMP Thu Jan 9 09:33:55 -03 2025 aarch64 GNU/Linux
root@r5s:~# gzip -cd /proc/config.gz | grep PREEMPT
CONFIG_PREEMPT_NONE_BUILD=y
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
# CONFIG_PREEMPT_RT is not set
# CONFIG_PREEMPT_DYNAMIC is not set
CONFIG_HAVE_PREEMPT_DYNAMIC=y
CONFIG_HAVE_PREEMPT_DYNAMIC_KEY=y
CONFIG_PREEMPT_NOTIFIERS=y
# CONFIG_PREEMPTIRQ_DELAY_TEST is not set
The point here is that this setting (both of them) increase the reaction of applications, which is relevant for UIs only, i.e. possible delays when you run a program/command, select something in a GUI and stuff like that, while the system is at high load from other/background tasks. So it is not necessarily relevant for desktop systems only, but also when you often use the console or some web interface interactively, while background services are running which cause high load by times.
And yes, makes sense that it does not change something on idle load/temperature, since it really only comes into play when the system is at high load already, and then interactive tasks want to interrupt those, to give the user response with shorter delay.
But thanks for testing different kernel configs. What I write above is based on what I read in the docs, but with my still limited understand of kernel internals. So always good to verify, and nice for me to have my assumptions verified.
