On 05/12/2018 10:19 PM, Joel Fernandes wrote:
On Tue, May 08, 2018 at 10:42:37AM +0100, Quentin Perret wrote:
On Tuesday 08 May 2018 at 11:09:57 (+0200), Dietmar Eggemann wrote:
On 05/08/2018 10:22 AM, Viresh Kumar wrote:
On 08-05-18, 08:33, Dietmar Eggemann wrote:
This reverts commit e2cabe48c20efb174ce0c01190f8b9c5f3ea1d13.

Lifting the restriction that the sugov kthread is bound to the
policy->related_cpus for a system with a slow switching cpufreq driver,
which is able to perform DVFS from any cpu (e.g. cpufreq-dt), is not
only not beneficial it also harms Enery-Aware Scheduling (EAS) on
systems with asymmetric cpu capacities (e.g. Arm big.LITTLE).

The sugov kthread which does the update for the little cpus could
potentially run on a big cpu. It could prevent that the big cluster goes
into deeper idle states although all the tasks are running on the little

I think the original patch did the right thing, but that doesn't suit
everybody as you explained.

I wouldn't really revert the patch but fix my platform's cpufreq
driver to set dvfs_possible_from_any_cpu = false, so that other
platforms can still benefit from the original commit.

This would make sure that the kthreads are bound to the correct set of cpus
for platforms with those cpufreq drivers (cpufreq-dt (h960), scmi-cpufreq,
scpi-cpufreq) but it will also change the logic (e.g.
sugov_should_update_freq() -> cpufreq_can_do_remote_dvfs()).

I'm still struggling to understand when a driver/platform should set
dvfs_possible_from_any_cpu to true and what the actual benefit would be.

I assume it might be beneficial to have the kthread moving around freely
in some cases, but since it is a SCHED_DEADLINE task now it can't really
migrate anywhere anyway. So I'm not sure either if this commits still makes
sense now. Or is there another use case for this ?

The usecase I guess is, as Dietmar was saying, that it makes sense for
kthread to update its own cluster and not disturb other clusters or random
CPUs. I agree with this point.

I agree with Viresh. Also, why exactly did we make it deadline instead of RT? Was RT not getting scheduled quick enough? Is it because Android creates a lot of RT threads?


Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project

Reply via email to