auto-cpufreq

[mews-se]

Since Dietpi is a light weight repo, it would make sense to use Adrians auto-cpufreq for supported hardware.

What do you think?

https://github.com/AdnanHodzic/auto-cpufreq

[MichaIng]

DietPi ships its own cpu info command, and boot script which sets CPUFreq schedutil governor and min/max scheduling frequencies by default, and handles Intel p-states incl. turbo boost as well if present. dietpi-config allows to adjust governor settings. An additional tool which can do the same/similar does not make it more lightweight 😉.

Which additional features this tool serves are needed? I mean we can add it as software option, if someone finds time to implement.

[mews-se]

Ah, excellent. I thought that auto-cpufreq was more "on it", but I could be mistaken.

And I agree that it doesnt make it MORE light weight :)

[MichaIng]

I checked a bit more what it does, and I do not agree it is reasonable:

• It suggests and can automatically switch between performance and powersave governor, based on whether PSU is attached or systems runs on battery. Of course this anyway only matters for a mobile device, or if you have a backup battery for your static system, though then it also depends on whether this battery is properly detected by the system, usually not the case. However, for a laptop this sounds good, but is nonsense, IMO.
  • The performance governor basically always runs all cores on max frequency. With the Intel p-states driver, it still seems to vary it a bit, also since turbo boost comes additionally into play, but the demo video of the tool demonstrates how the cores all run very close to max all the time. Even that the system is on PSU, this is a waste of energy, heats up the device unnecessarily, potentially degrades lifetime, spins up active cooling => additional noise etc. Only use case is some very old CPUs which have no stable low p-states, or are simply not able to do their job well when scaling up and down regularly. The Sparky SBC was such a case, sold by Allo for their audiophile hardware, but the CPU was too old/weak to play audio without shuttering with a dynamic governor, at least when some conversion or streaming is additionally involved. And it did not have heat problems at max frequency either.
  • The powersave governor, being the opposite, always runs all cores at minimum frequency, means it slows down everything you do, including interactive tasks, which is definitely not what I want my laptop to do as fast as I unplug its power. Even if you do not care about performance: lowering the frequency means that your cores are at higher load for longer times, despite, or better because they stay at min frequency. Longer activity means also longer I/O on RAM, disk etc, and other hardware components like WiFi or whatever is involved and waiting for the CPU to finish its task, being active longer, and potentially hold longer from going back into their idle/powersave states. This governor is old, named a long time ago when there was no good frequency scaling, but nowadays I would highly question whether it really reduces overall power consumption when needing to finish the same tasks. Similarly, I see no real use case for this, aside of some crappy hardware that simply heats up much too fast, and you do not want/cannot cool it properly, and/or if the system is not used for anything interactive, but does only/constant low load tasks, like reading and/or streaming sensor data 24/7: for such you need no CPU performance, of course.
  • The Linux kernel does automatic frequency scaling based on load, which is the whole point of CPUFreq, with governors like ondemand, interactive, conservative, and their modern successor schedutil. Especially the latter reduces frequency to minimum very quickly if there is no load. So as long as one is not causing constant high load, it is over time almost the same average frequency as with powersave governor. Here my home server's time in CPU states with schedutil governor:

    root@micha:~# cat /sys/devices/system/cpu/cpufreq/policy*/stats/time_in_state
    408000 81406756
    600000 64050
    816000 272918
    1008000 28611
    1200000 65965
    1416000 16676
    1608000 5308
    1800000 9101
    408000 81816891
    600000 16803
    816000 4785
    1008000 3727
    1200000 3241
    1416000 2722
    1608000 6409
    1800000 1606
    2016000 1183
    2208000 1022
    2400000 10993
    408000 81822194
    600000 15707
    816000 4445
    1008000 2768
    1200000 2661
    1416000 2625
    1608000 5997
    1800000 1650
    2016000 1324
    2208000 1087
    2400000 8923

    This is 3 policies for 8 CPUs. Even the 4 small CPUs, intended for low/idle load (upper policy), about 99.5% of the time they are at lowest 408 MHz frequency. The 4 large cores above 99.9% of the time. But IF I access my Nextcloud's web UI, or the daily (nightly) backup runs, or I work on its console, the CPUs go up in a microsecond and I have full performance as needed, and as I expect.
  • Intel turbo boost as well activates on demand. The tool enables and disables it based on battery and CPU load, but especially on CPU load ... I mean this is again the whole point of turbo boost: giving some additional short term power on high load situations, quickly. Disabling it, and enabling it again with some software daemon that watches CPU load in of course much longer intervals than a native CPU feature can do, breaks its purpose.
  • And of course, having a daemon running that is monitoring CPU load and battery status all the time, switching back and forth CPUFreq settings, causes load and hence consumes battery by itself.

So really, the tool seems to try solving issues which do not exist since at least a decade, either wasting energy or degrading your system's performance/reactivity unnecessarily. Use a dynamic governor, and let it do its job. This is what they are made for, with a lot of hardware and Linux specialists knowledge going inside. schedutil governor should be fine in 99% of cases. If really some more control is needed for sensitiv systems, or if schedutil is ramping up the frequency too slow or not well aligned with I/O load (there are cases), use:

• conservative for slower frequency adjustments, helping when old crappy hardware has stability/voltage issues with fast adjustments
• ondemand with lowered upscale threshold: by default set to 50% means it sets the CPU frequency immediately to max once 50% CPU load has been reached. That way, while it will overshoot in most cases, it makes the system very reactive. And it can be configured to consider disk I/O as load as well. schedutil has been observed to reduce disk I/O speeds in some cases, as it leaves all/some cores (the large ones in big.LITTLE cases) at min frequency, if there is no (other) higher CPU load.

A software solution cannot do a better job than a native kernel feature that works with native hardware features.

[mews-se]

Thanks, that's a proper deep dive!

[MichaIng]

Checking a bit further, I need to revert the statement partially: In case the Intel p-states scheduling driver runs in "active" mode, which is the default if the CPU supports hardware-wise frequency scaling, there are only the two governors powersave and performance available, which differ from the CPUFreq ones: Both are dynamic governors, just tuned a bit more in the one or other direction. How exactly they work, depends on the hardware, so it is a bit similar to schedutil in these regards.

So if one has an Intel CPU that is new enough to support HWP (hardware p-states), with Intel p-states scheduler in active mode, the tool switches make somewhat sense. But only somewhat: I personally still do not see much use cases which satisfy the additional steps to install, maintain/update the tool, as well as the additional load its daemon causes. I mean how often does one travel with a laptop or so, too long for the battery to survive. Also, when using it for work and not for gaming, which application/usage really benefits from the performance governor, rather than the powersave one (default). And if it is used for gaming, playing shooters or MMOs or any such where reactivity is essential, so that performance governor makes sense, is it really intended that it switches to powersave as fast as PSU is detached?

And e.g. my laptop (AMD CPU) has a battery lifetime saving setting, so that it charges up to 70% and then lets it decharge down to 40%, before it is charged again, so that the battery stays neither at very low nor very high load, in stationary usage. The tool would in such case unnecessarily switch governors back and forth, even that the PSU is attached at all time, just intentionally not keeping it at 100%.

So my main point remains true: choose a governor based on your use case and let kernel and hardware features do their job.

As a side node: it is possible to enforce active and passiv mode. Passiv mode means that the Intel p-states scheduler uses/exposes the default CPUFreq governors instead. And it is possible to load the generic Linux acpi-cpufreq kernel module as scheduler instead.