Great suggestion Dom, abt the gpu_freq_min
My settings are now ...There is no measurable boot delay, and no deficiency of memory rate with idle current at 71ma/96ma !!!
(memory test: "sysbench memory --threads=4 run" for several iterations).
Setting gpu_freq_min=10, seems to work reliably with negligible power improvement. Lower figures like =1 with 'ondemand' governor can have bad interactions, like huge ~10 second process latency. For example typed characters via ssh may not echo for seconds ! Changing the governor from 'ondemand' to performance or 'powersave' fixes this issue. I *suspect* that the governors changing frequency requires the vcio (vid controller) and then *if* the gpu_freq is too low, the system hands for a long time for the cpu frequency changes.
It would be better if the rpi ARM cpus had a true idle state, but ...
===
WIth respect to governors (conservative ondemand userspace powersave performance schedutil), these cannot improve idle power, for obvious reasons.
The choice of governor greatly depends on the compute load that must executed so these are only lower-power with respect to a particular computational requirement.
===
Interesting point, /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency returns CPUFREQ_ETERNAL.
I've examined the kernel code, and the raspberry pi cpufreq_dt code makes no attempt to calculate the latency.
The kernel docs say ...
My settings are now ...
Code:
gpu_freq=300gpu_freq_min=20initial_turbo=40(memory test: "sysbench memory --threads=4 run" for several iterations).
Setting gpu_freq_min=10, seems to work reliably with negligible power improvement. Lower figures like =1 with 'ondemand' governor can have bad interactions, like huge ~10 second process latency. For example typed characters via ssh may not echo for seconds ! Changing the governor from 'ondemand' to performance or 'powersave' fixes this issue. I *suspect* that the governors changing frequency requires the vcio (vid controller) and then *if* the gpu_freq is too low, the system hands for a long time for the cpu frequency changes.
It would be better if the rpi ARM cpus had a true idle state, but ...
===
WIth respect to governors (conservative ondemand userspace powersave performance schedutil), these cannot improve idle power, for obvious reasons.
The choice of governor greatly depends on the compute load that must executed so these are only lower-power with respect to a particular computational requirement.
===
Interesting point, /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_transition_latency returns CPUFREQ_ETERNAL.
I've examined the kernel code, and the raspberry pi cpufreq_dt code makes no attempt to calculate the latency.
The kernel docs say ...
So the time to transition cpu frequency has unknown latency, making the default governor 'ondemand' a dubious choice if you are tweaking clock rates (it seems to work fine for default clocks).cpuinfo_transition_latency
The time it takes to switch the CPUs belonging to this policy from one P-state to another, in nanoseconds.
If unknown or if known to be so high that the scaling driver does not work with the ondemand governor, -1 (CPUFREQ_ETERNAL) will be returned by reads from this attribute.
Statistics: Posted by steveja — Thu Oct 02, 2025 1:32 pm
