lkml.org 
[lkml]   [2020]   [Jan]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    Patch in this message
    /
    Date
    From
    SubjectRe: [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

    \
     
     \ /
      Last update: 2020-01-23 17:17    [W:4.132 / U:0.372 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site