Re: [PATCH 2/2] cpufreq: intel_pstate: Fix set_policy interface for no_turbo

[Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>]

On Wed, 2016-06-08 at 02:50 +0200, Rafael J. Wysocki wrote:
> On Wed, Jun 8, 2016 at 2:48 AM, Srinivas Pandruvada
> <srinivas.pandruvada@linux.intel.com> wrote:
> > 
> > On Wed, 2016-06-08 at 02:42 +0200, Rafael J. Wysocki wrote:
> > > 
> > > On Wed, Jun 8, 2016 at 2:38 AM, Srinivas Pandruvada
> > > <srinivas.pandruvada@linux.intel.com> wrote:
> > > > 
> > > > 
> > > > When turbo is disabled, the set_policy interface is broken.
> > > > For example, when turbo is disabled and
> > > > cpuinfo.max = 2900000 (full max turbo frequency)
> > > > Setting the limits results in frequency less than settings:
> > > > Set 1000000 KHz results in 0700000 KHz
> > > > Set 1500000 KHz results in 1100000 KHz
> > > > Set 2000000 KHz results in  1500000 KHz
> > > > 
> > > > This is because limits->max_perf fraction is calculated using
> > > > max
> > > > turbo frequency as the reference, but when the max P-State is
> > > > capped in the function intel_pstate_get_min_max, the reference
> > > > is not the max turbo P-State. This results in reducing max
> > > > P-State.
> > > > 
> > > > One option is to always use max turbo as reference for
> > > > calculating
> > > > limits. But this will not be correct. By definition the
> > > > intel_pstate
> > > > sysfs limits, shows percentage of available performance. So
> > > > when
> > > > BIOS has disabled turbo, the available performance is max non
> > > > turbo.
> > > > So the max_perf_pct should still show 100%.
> > > > 
> > > > Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.i
> > > > ntel
> > > > .com>
> > > I guess we need this in -stable?
> > Yes.
> > > 
> > > 
> > > If so, all of them, or is there a specific starting point?
> > I think this is from (even in 3.10, it should have the same
> > behavior
> > looking at the code).
> OK
> 
> All applicable, then?
Yes. But for some of the trees we need rebase, as the patch may not
apply cleanly.

Thanks,
Srinivas