Instantaneous vs. cummulative cpufreq stats

[iustin]

Hi,

Looking around at issues such as #122 and #123, I see that in both cases, what is collected is the current (i.e. instantaneous) state of the CPUs, either hardware (cpufreq_* counters) or software (scaling_*_freq).

However, if compiled as such, the kernel does provide cummulative statistics via the stats/ subdirectory - see https://www.kernel.org/doc/html/latest/cpu-freq/cpufreq-stats.html.

I think the time_in_state is the most interesting, followed by total_trans. These would allow much better fidelity of historical CPU state.

Thoughts?

[rexagod]

+1. Looping in @discordianfish to check if this request makes sense, and if so, I'd be happy to raise a PR. (:

[discordianfish]

Agreed, I think that would make sense

[iustin]

Thanks both, I forgot to track this. Would be really good to have cumulative stats.

[rexagod]

trans_table and time_in_state seem to exhibit a high cardinality nature owing to the CPU frequencies they track. total_trans seems fine to generate metrics for, though.

[iustin]

Hmm. total_trans is interesting, but mostly a gimmick. Looking at one of my systems that has this module compiled, time_in_state has 10 rows, per CPU, so indeed that's a lot of metrics, but it is the real file that gives the data.

How about hiding this behind a flag, so only people interested enable it? It needs anyway a kernel module, that might not be always available.

[SuperQ]

I think time_in_state metrics make the most useful data.

As this is a generically useful library, the decision on metrics exposition would happen in something like the node_exporter.