On Tuesday 16 Apr 2019 at 15:38:41 (-0400), Thara Gopinath wrote: > diff --git a/drivers/thermal/cpu_cooling.c b/drivers/thermal/cpu_cooling.c > @@ -177,6 +178,9 @@ static int cpufreq_thermal_notifier(struct notifier_block > *nb, > > if (policy->max > clipped_freq) > cpufreq_verify_within_limits(policy, 0, clipped_freq); > + > + sched_update_thermal_pressure(policy->cpus, > + policy->max, policy->cpuinfo.max_freq);
Is this something we could do this CPUFreq ? Directly in cpufreq_verify_within_limits() perhaps ? That would re-define the 'thermal pressure' framework in a more abstract way and make the scheduler look at 'frequency capping' events, regardless of the reason for capping. That would reflect user-defined frequency constraint into cpu_capacity, in addition to the thermal stuff. I'm not sure if there is another use case for frequency capping ? Perhaps the Intel boost stuff could be factored in there ? That is, at times when the boost freq is not reachable capacity_of() would appear smaller ... Unless this wants to be reflected instantaneously ? Thoughts ? Quentin
