On Thursday 17 Dec 2020 at 16:20:49 (+0530), Viresh Kumar wrote: > On 16-12-20, 19:37, Ionela Voinescu wrote: > > I did not yet test this, but reading this comment made me wonder.. > > > > arch_scale_freq_invariant() (or topology_scale_freq_invariant()) is also > > called from schedutil when obtaining the next frequency. > > > > So if we had a system that only partly supports AMUs but had at some > > point a cpufreq driver that provided FIE for the other CPUs, when we > > unregister the driver, the cpufreq_freq_invariance static key is > > disabled. Therefore, none of the conditions for system invariance is > > now accomplished and arch_scale_freq_invariant() will return false. > > This will be broken as utilization is still scaled, but the algorithm > > for computing the next frequency in schedutil will not take this into > > account. > > I think the best and the easiest solution for this is: > > bool arch_freq_counters_available(const struct cpumask *cpus) > { > return amu_freq_invariant(); > } > > But we probably need to rename it to something like arch_is_fie(). >
Now that I think of it again (after spending 30 minutes trying to come up with a more clear solution) I realised this is not actually a problem :). The only location that checks the invariance status is schedutil, but what a cpufreq governor does becomes irrelevant if you remove the cpufreq driver. The only potential problem is if one then inmods a cpufreq driver that's not invariant. But I think that might be on "if" too many to consider. What do you think? Thanks, Ionela.