...I can't say whether it's "strictly" between them or not because driver->get()
Hi Beata,Hi Jie,
I've recently tested this patchset on a Kunpeng system.Thank you for giving it a spin.
It works as expected when reading scaling_cur_freq.
The frequency samples are much stabler than what cppc_cpufreq returns.
(and apologies for late reply)
A few minor things.All right - will look into it.
1. I observed larger errors on idle cpus than busy cpus, though it's just up
to 1%.
Not sure if this comes from the uncertain time interval between the last
tick and entering idle.
The shorter averaging interval, the larger error, I supposed.
Just for my benefit: that diff is strictly between arch_freq_avg_get_on_cpu
and cpufreq_driver->get(policy->cpu) ?
Yeah I understood this.2. In the current implementation, the resolution of frequency would be:arch_freq_get_on_cpu relies on the frequency scale factor to derive the average
max_freq_khz / SCHED_CAPACITY_SCALE
This looks a bit unnecessary to me.
It's supposed to get a better resolution if we can do this in
arch_freq_get_on_cpu():
freq = delta_cycle_cnt * max_freq_khz / delta_const_cnt
which may require caching both current and previous sets of counts in the
per-cpu struct amu_cntr_sample.
frequency. The scale factor is being calculated based on the deltas you have
mentioned and arch_max_freq_scale which uses SCHED_CAPACITY_SCALE*2 factor to
accommodate for rather low reference frequencies. arch_freq_get_on_cpu just does
somewhat reverse computation to that.
---
BR
Beata
Kind regards,
Jie