Messages in this thread Patch in this message | | | Date | Thu, 23 Jan 2020 16:16:44 +0000 | From | Quentin Perret <> | Subject | Re: [RFC PATCH v4 3/6] sched/cpufreq: Hook em_pd_get_higher_power() into get_next_freq() |
| |
On Wednesday 22 Jan 2020 at 17:35:35 (+0000), Douglas RAILLARD wrote: > @@ -210,9 +211,16 @@ static unsigned int get_next_freq(struct sugov_policy *sg_policy, > struct cpufreq_policy *policy = sg_policy->policy; > unsigned int freq = arch_scale_freq_invariant() ? > policy->cpuinfo.max_freq : policy->cur; > + struct em_perf_domain *pd = sugov_policy_get_pd(sg_policy); > > freq = map_util_freq(util, freq, max); > > + /* > + * Try to get a higher frequency if one is available, given the extra > + * power we are ready to spend. > + */ > + freq = em_pd_get_higher_freq(pd, freq, 0);
I find it sad that the call just below to cpufreq_driver_resolve_freq() and cpufreq_frequency_table_target() iterates the OPPs all over again. It's especially a shame since most existing users of the EM stuff do have a cpufreq frequency table.
Have you looked at hooking this inside cpufreq_driver_resolve_freq() instead ? If we have a well-formed EM available, the call to cpufreq_frequency_table_target() feels redundant, so we might want to skip it.
Thoughts ?
Quentin
| |