Re: [PATCH 0/4] cpufreq governors and Intel P state driver compatibility

[Thomas Renninger <trenn@suse.de>]

On Friday, December 04, 2015 04:08:34 PM Srinivas Pandruvada wrote:
> Intel P State driver implements two policies, performance and powersave.
> The powersave policy is similar to ondemand cpufreq governor when using
> acpi-cpufreq. This causes lots of confusion among users. This results
> in invalid comparison of performance when acpi-cpufreq and Intel P state
> performance is compared.

After several years you want to change this again?

We released documentation for this for SLE 12 recently.
It was not that easy to phrase, but it would be wrong again with newer
kernels..., sigh.

But yeah, maybe this change should be finally made.
One idea, not sure it is better: Revert the powersave governor. Then it
is clear on which implemenation of intel_pstate you are running.
And you do not accidentially think you are adjusting freqs on powersave
governor but in real you are running fixed at lowest freq.

When you are looking at cleaning up intel_pstate driver here a
request/question from me on the cpufreq list from March 2014.
>From what I see, this is still valid and these pstate specific sysfs
knobs exist as general cpufreq files already. So the pstate ones should
vanish:

1) sysfs tunables:
   - max_perf_pct, min_perf_pct
     According to Documentation/cpu-freq/intel-pstate.txt this is:
      max_perf_pct: limits the maximum P state that will be requested by
      the driver stated as a percentage of the available performance.

      min_perf_pct: limits the minimum P state that will be  requested by
      the driver stated as a percentage of the available performance.

     Why is this needed, there already is:
     scaling_max_freq, scaling_min_freq

     How are both connected?
     For me those tunable are doing the same and intel_pstate specific ones
     should vanish to have one cpufreq min/max frequency interface exported
     to userspace on all archs/cpufreq drivers.

   - no_turbo: limits the driver to selecting P states below the turbo
     frequency range.

     Again, there is the general cpufreq "boost" tunable defined in cpufreq.c:
     ssize_t show_boost(..)
     static ssize_t store_boost(...)
     define_one_global_rw(boost);

     What is the difference, why does intel-pstate need its own tunable?

    Thomas