Keep cpufrequtils settings when linux-root upgrades

[5kft]

I'm curious as to why we explicitly specify CPUMIN and CPUMAX values in the Armbian board configs, for most/all boards...  These values of course propagate their way into the MIN_SPEED and MAX_SPEED settings in the target /etc/default/cpufrequtils configuration file (e.g., see lib/makeboarddeb.sh).

 

If these values aren't specified, then the cpufreq driver will base its speed ranges on what the underlying H/W supports (e.g., specified via the board DT(s)).

 

So...if the underlying driver configuration provides the supported speed range, then we actually need to specify these values?

 

I ask because I'm running my H5 boards with my overlays that increase the maximum clock rates to 1.3GHz/1.4GHz, and every time I do an Armbian nightly upgrade and the BSP package is upgraded, I have to re-edit /etc/default/cpufrequtils and remove the MAX_SPEED line (e.g., from the default of 816MHz).  It seems like this should not be necessary as the DT already configures the correct/supported maximum speed...

 

Would it make sense to remove some of these explicit configuration settings for boards that we know will operate correctly based on the DT configs (e.g., edit config/boards/...conf appropriately?)

 

Anyway just a question/thought...thanks!

 

[tkaiser]

56 minutes ago, 5kft said:

I ask because I'm running my H5 boards with my overlays that increase the maximum clock rates to 1.3GHz/1.4GHz, and every time I do an Armbian nightly upgrade and the BSP package is upgraded, I have to re-edit /etc/default/cpufrequtils and remove the MAX_SPEED line (e.g., from the default of 816MHz)

 

Honestly: I think you're the only one doing this

 

The reasons to specify these settings are as follows:

• CPUMIN: Some kernels/settings define awfully low cpufreq OPP that result in no further consumption savings but crappy IO performance (e.g. Tinkerboard: the default kernel defines lowest cpufreq as low as 100 MHz which makes zero difference to 600 MHz from a consumption/heat point of view but destroys IO performance with ondemand governor since clockspeeds do not ramp up quickly enough)
• CPUMAX: Sometimes used to allow users who know what they do to enter experimental area while keeping safe defaults (e.g. allowing Rock64 to clock up to 1.5GHz by patching DT but since we had some reports about instabilities at 1.5 GHz defining CPUMAX still as 1.4GHz -- for an experienced user it's a lot easier to adjust a config file than to deal with overlays on most platforms or playing around with dtc binary)

I agree that current situation with overwriting /etc/default/cpufrequtils with board support package updates is not ideal. But no idea how to improve situation. My personal workaround is two lines in /etc/rc.local overwriting /etc/default/cpufrequtils contents and reloading the daemon.

[chwe]

1 hour ago, tkaiser said:

But no idea how to improve situation. My personal workaround is two lines in /etc/rc.local overwriting /etc/default/cpufrequtils contents and reloading the daemon.

maybe a script in rc6.d (at reboot) together with an entry in armbian-config? most likely BSP gets updated with the kernelupdate right? So you'll reboot the board anyway. Not sure if someone ever wrote an startscript in rc6 and if this is sane.. :S 

[5kft]

1 hour ago, tkaiser said:

Honestly: I think you're the only one doing this

 

Yes, I think that you are right - LOL!

 

Quote

The reasons to specify these settings are as follows:

• CPUMIN: Some kernels/settings define awfully low cpufreq OPP that result in no further consumption savings but crappy IO performance (e.g. Tinkerboard: the default kernel defines lowest cpufreq as low as 100 MHz which makes zero difference to 600 MHz from a consumption/heat point of view but destroys IO performance with ondemand governor since clockspeeds do not ramp up quickly enough)
• CPUMAX: Sometimes used to allow users who know what they do to enter experimental area while keeping safe defaults (e.g. allowing Rock64 to clock up to 1.5GHz by patching DT but since we had some reports about instabilities at 1.5 GHz defining CPUMAX still as 1.4GHz -- for an experienced user it's a lot easier to adjust a config file than to deal with overlays on most platforms or playing around with dtc binary)

I agree that current situation with overwriting /etc/default/cpufrequtils with board support package updates is not ideal. But no idea how to improve situation. My personal workaround is two lines in /etc/rc.local overwriting /etc/default/cpufrequtils contents and reloading the daemon.

 

OK, thank you very much!  This is exactly the perspective I was looking for.  I was originally planning on doing a simple sed line in rc.local to comment this out (followed by a service restart), but wanted to ask this question first just in case.

 

One could argue that for some boards we keep CPUMIN/CPUMAX defined (as you note), and for others (thoroughly tested) they could be removed, but it is also wise to be as careful and conservative as possible when it comes to this, as we don't want to introduce instability or unintended side effects.

 

Thanks again 

[5kft]

19 minutes ago, chwe said:

maybe a script in rc6.d (at reboot) together with an entry in armbian-config? most likely BSP gets updated with the kernelupdate right? So you'll reboot the board anyway. Not sure if someone ever wrote an startscript in rc6 and if this is sane.. :S 

 

I like that idea!  However as @tkaiser notes it'd probably be overkill for the number of people that would actually use it (i.e., just me) 

[j4m3z0r]

Hi all,

 

Fairly new to Armbian, and loving it so far. I'm running on a FriendlyElec NanoPi Neo Core 2 for a project I'm working on. I want to use the "conservative" cpufreq governor and set the max frequency to around 800MHz (battery and heat dissipation concerns). I've been able to do this by editing the /etc/defaults/cpufrequtils file, however (and there's a warning to this effect in the file) it gets overwritten whenever the linux-root package gets upgraded.

 

I can think of some hacks to workaround this (eg re-setting those settings in /etc/rc.local), but I figured I'd check in here to see if there's a more robust, less hacky way to fix this. Is there a configuration flag to prevent this overwriting? Will something like chattr +i work, or will that break future upgrades?

 

Would appreciate any pointers on a good way to solve this. Thanks!

[chwe]

On 9/20/2018 at 1:32 AM, 5kft said:

However as @tkaiser notes it'd probably be overkill for the number of people that would actually use it (i.e., just me) 

one more and you can set up a punk band.. 

 

still think that putting something like this in rc6.d just asks for trouble.. 

[j4m3z0r]

Yeah, I'm not crazy about startup scripts that then modify other startup scripts. I've just tried chattr +i on it, so I guess I'll see if it breaks the next time there's an update (at least I'll know about it if it breaks). However, as a less bad solution, what about adding a "PERSIST_ON_UPGRADE" flag to that file, which the dpkg scripts check for? If it's set, then the upgrade shouldn't overwrite the file.

[5kft]

 

2 hours ago, chwe said:

one more and you can set up a punk band.. 

 

LOL!!  

 

FWIW, my workaround hack at the moment is to simply do this in /etc/rc.local (yes, this could be cleaner , but hey it works for now):

# set maximum cpufreq speed
(sleep 10; cat /sys/devices/system/cpu/cpufreq/policy0/cpuinfo_max_freq >/sys/devices/system/cpu/cpufreq/policy0/scaling_max_freq) &

This is nice as there is no config file rewriting or anything.  It simply sets the new maximum scaling frequency after cpufrequtils initializes, in the background.  (You could of course set whatever maximum frequency you would like using this method.)

[lrrr]

Does dpkg-divert not work for some reason?

dpkg-divert --add /etc/default/cpufrequtils

[chwe]

merged both threads, cause I think it actually makes sense..  

 

2 hours ago, 5kft said:

 

3 hours ago, chwe said:

one more and you can set up a punk band.. 

 

LOL!!  

 

I think there's your drummer (or guitarist.. or whatever.. )..  

19 minutes ago, lrrr said:

Does dpkg-divert not work for some reason?

dpkg-divert --add /etc/default/cpufrequtils

 

Edited September 26, 2018 by chwe
moved topic back where it should be...

[5kft]

4 hours ago, chwe said:

 

I think there's your drummer (or guitarist.. or whatever.. )..  

 

 

I think we have a lead singer   Thanks @lrrr, that is great to know!!