cpufreq: dynamically alloc MAX_AVAIL_FREQS according to time_in_state

[zzzyhtheonly]

Hi, there is an error report "cpufreq plugin: Found too many frequency states (21 > 20). Plugin needs to be recompiled. Please open a bug report for this." on our machines.

We are using Nvidia's ARMv8 processors and Linux kernel based on 4.14.150. We find that there are more than 20 in cpu's freq table:

cat /sys/devices/system/cpu/cpu0/cpufreq/stats/time_in_state | wc -l
23

We try to resolve this by making MAX_AVAIL_FREQS a configurable variable in conf file in order to avoid recompiling. And it is tested on our machines (we make MAX_AVAIL_FREQS to 30 in our conf files).
Please help review if this idea works, if not, should we simply change MAX_AVAIL_FREQS into a bigger one?
Thanks a lot!

ChangeLog: cpufreq: make MAX_AVAIL_FREQS configurable in conf

[eero-t]

Changing plugin to allocate the array dynamically is good idea, but this PR does not go far enough. Code should check how many CPUs there actually are, and allocate enough space for all of them instead of requiring user to determine that.

PS. Nowadays 20 cores is indeed a ridiculously low number, as there are servers with much larger core counts.

[zzzyhtheonly]

@eero-t
Thanks for your comment! MAX_AVAIL_FREQS states the total number of frequencies supported by
each CPU, referenced at https://www.kernel.org/doc/Documentation/cpu-freq/cpufreq-stats.txt
But yes, we should check how many frequencies there actually are instead of requiring users to determine that, so I patch this PR and please help review again. Thanks!

[mrunge]

Thank you for the PR, this looks like a really good idea. I wouldn't mind to start with a larger number (e.g 128) from the beginning.

The CI failures are unfortunately known and not caused by this PR!

[mrunge]

thank you!