Messages in this thread | | | Date | Thu, 18 Apr 2019 10:48:35 +0100 | From | Quentin Perret <> | Subject | Re: [PATCH V3 3/3] thermal/cpu-cooling: Update thermal pressure in case of a maximum frequency capping |
| |
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
| |