Re: [PATCH V3 1/2] topology: Allow multiple entities to provide sched_freq_tick() callback
From: Viresh Kumar <viresh.kumar@linaro.org>
Date: 2021-02-17 11:46:51
Also in:
linux-pm, lkml
On 17-02-21, 11:30, Ionela Voinescu wrote:
The problem is not topology_scale_freq_invariant() but whether a scale factor is set for some CPUs. Scenario (test system above): - "AMUs" are only supported for [1-2], - cpufreq_supports_freq_invariance() -> false What should happen: - topology_scale_freq_invariant() -> false (passed) - all CPUs should have their freq_scale unmodified (1024) - (failed) because only 2 out of 6 CPUs have a method of setting a scale factor What does happen: - arch_set_freq_tick() -> topology_set_freq_tick() will set a scale factor for [1-2] based on AMUs. This should not happen. We will end up with invariant signals for bigs and signals that are not freq invariant for littles.
Another case. cpufreq is included as a module and AMU is implemented partially. - first time cpufreq driver is inserted, we set up everything and freq_scale gets updated on ticks. - remove cpufreq driver, we are back in same situation. We can't control it that way.. Or we add another call layer in middle before the tick-handler gets called for AMU, which will check if we are fully invariant or not ? -- viresh _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel