lkml.org 
[lkml]   [2016]   [Oct]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [PATCH] cpufreq: intel_pstate: Set P-state upfront in performance mode
On Thu, Oct 20, 2016 at 8:22 PM, Srinivas Pandruvada
<srinivas.pandruvada@linux.intel.com> wrote:
> On Wed, 2016-10-19 at 02:57 +0200, Rafael J. Wysocki wrote:
>> From: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>
>
> [...]
>
>> + if (policy->policy == CPUFREQ_POLICY_PERFORMANCE) {
>> + /*
>> + * NOHZ_FULL CPUs need this as the governor callback
>> may not
>> + * be invoked on them.
>> + */
>> + intel_pstate_clear_update_util_hook(policy->cpu);
>> + intel_pstate_max_within_limits(cpu);
>> + }
>> +
>
> Can we move this to intel_pstate_set_performance_limits
>
> diff --git a/drivers/cpufreq/intel_pstate.c
> b/drivers/cpufreq/intel_pstate.c
> index a6ffd79..d0fd73e 100644
> --- a/drivers/cpufreq/intel_pstate.c
> +++ b/drivers/cpufreq/intel_pstate.c
> @@ -1543,6 +1543,13 @@ static void
> intel_pstate_set_performance_limits(struct perf_limits *limits)
> limits->max_sysfs_pct = 100;
> limits->min_policy_pct = 0;
> limits->min_sysfs_pct = 0;
> +
> + /*
> + * NOHZ_FULL CPUs need this as the governor callback may not
> + * be invoked on them.
> + */
> + intel_pstate_clear_update_util_hook(policy->cpu);
> + intel_pstate_max_within_limits(cpu);
> }
>
> static int intel_pstate_set_policy(struct cpufreq_policy *policy)
> @@ -1599,15 +1606,6 @@ static int intel_pstate_set_policy(struct
> cpufreq_policy *policy)
> limits->max_perf = round_up(limits->max_perf, FRAC_BITS);
>
> out:
> - if (policy->policy == CPUFREQ_POLICY_PERFORMANCE) {
> - /*
> - * NOHZ_FULL CPUs need this as the governor callback
> may not
> - * be invoked on them.
> - */
> - intel_pstate_clear_update_util_hook(policy->cpu);
> - intel_pstate_max_within_limits(cpu);
> - }
> -
> intel_pstate_set_update_util_hook(policy->cpu);
>
> intel_pstate_hwp_set_policy(policy);

Not really, because the policy->max < policy->cpuinfo.max_freq case
needs to be covered too.

At least I don't see why it shouldn't be covered.

Thanks,
Rafael

\
 
 \ /
  Last update: 2016-10-20 23:20    [W:0.077 / U:0.536 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site