I would recommend running latest version of my sbc-bench since the interactive mode will report probably performance relevant governors. Such governors are always about both performance and consumption at the same time as such even knowing where you could adjust stuff might point to tunables worth looking into.
The whole point of sbc-bench isn’t ‘yet another benchmark’ but understanding hardware, software, settings and capabilities better to act on accordingly.
On a Rock 5B for example sbc-bench will print this when starting:
Status of probably performance related governors below /sys:
dmc: powersave (dmc_ondemand userspace powersave performance simple_ondemand)
fb000000.gpu: simple_ondemand (dmc_ondemand userspace powersave performance simple_ondemand)
fdab0000.npu: userspace (dmc_ondemand userspace powersave performance simple_ondemand)
dmc is key to powersavings in idle. You’re running 5.15 so no idea whether dmc is there or not. It’s a feature of Rockchip’s BSP kernels and many such features get lost with mainline kernel. sbc-bench will tell.
As for ASPM (/sys/module/pcie_aspm/parameters/policy) I would be really careful with powersupersave. At least I got data corruption on both ARM and x86 with it. The lowest I would go is powersave.
Wi-Fi/BT is another good spot to look at if it’s not needed. Either by using a device-tree overlay to disable the respective nodes or by using rfkill in some start scripts.
Turning off internal SoC features (like HDMI, GPU) is usually done automagically with BSP kernels (the stuff from the SoC vendor) but often gets lost with mainline kernel. It’s often a bit tricky to measure since after a cold boot the HDMI PHY (and some GPU parts) may be active to be then disabled after n minutes of inactivity.
Using something like a Kill-A-Watt or some USB powermeter is often not sufficient to get the bigger picture since consumption fluctuations hide little gains and without longterm graphs that show tendencies stuff like “internal HDMI gets disabled automatically after 10 minutes” won’t be spotted.
LEDs are not worth the efforts since just a few mW so all that remains left to be checked is maybe broken/stupid DVFS settings (DVFS = dynamic voltage frequency scaling). Since you’re using an Armbian image you can rest assured that not a single brain cell has been wasted on this. At least not by anyone ‘working’ over at Armbian.
I tried to integrate DVFS OPP reporting into latest sbc-bench version (though requires an export MODE=extensive prior to starting the benchmark). But there’s at least one bug remaining reporting bogus clockspeeds. You could give it a try and I may fix it with your help on the way…
Everything about limiting count of CPU cores or limiting maximum cpufreq is more about reducing peak consumption and doesn’t affect idle (that much). As such a different area.
