1. 05 Mar, 2017 4 commits
    • Rafael J. Wysocki's avatar
      cpufreq: intel_pstate: Do not reinit performance limits in ->setpolicy · a240c4aa
      Rafael J. Wysocki authored
      If the current P-state selection algorithm is set to "performance"
      in intel_pstate_set_policy(), the limits may be initialized from
      scratch, but only if no_turbo is not set and the maximum frequency
      allowed for the given CPU (i.e. the policy object representing it)
      is at least equal to the max frequency supported by the CPU.  In all
      of the other cases, the limits will not be updated.
      
      For example, the following can happen:
      
       # cat intel_pstate/status
       active
       # echo performance > cpufreq/policy0/scaling_governor
       # cat intel_pstate/min_perf_pct
       100
       # echo 94 > intel_pstate/min_perf_pct
       # cat intel_pstate/min_perf_pct
       100
       # cat cpufreq/policy0/scaling_max_freq
       3100000
       echo 3000000 > cpufreq/policy0/scaling_max_freq
       # cat intel_pstate/min_perf_pct
       94
       # echo 95 > intel_pstate/min_perf_pct
       # cat intel_pstate/min_perf_pct
       95
      
      That is confusing for two reasons.  First, the initial attempt to
      change min_perf_pct to 94 seems to have no effect, even though
      setting the global limits should always work.  Second, after
      changing scaling_max_freq for policy0 the global min_perf_pct
      attribute shows 94, even though it should have not been affected
      by that operation in principle.
      
      Moreover, the final attempt to change min_perf_pct to 95 worked
      as expected, because scaling_max_freq for the only policy with
      scaling_governor equal to "performance" was different from the
      maximum at that time.
      
      To make all that confusion go away, modify intel_pstate_set_policy()
      so that it doesn't reinitialize the limits at all.
      
      At the same time, change intel_pstate_set_performance_limits() to
      set min_sysfs_pct to 100 in the "performance" limits set so that
      switching the P-state selection algorithm to "performance" causes
      intel_pstate/min_perf_pct in sysfs to go to 100 (or whatever value
      min_sysfs_pct in the "performance" limits is set to later).
      
      That requires per-CPU limits to be initialized explicitly rather
      than by copying the global limits to avoid setting min_sysfs_pct
      in the per-CPU limits to 100.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      a240c4aa
    • Rafael J. Wysocki's avatar
      cpufreq: intel_pstate: Fix intel_pstate_verify_policy() · d74b1992
      Rafael J. Wysocki authored
      The code added to intel_pstate_verify_policy() by commit 1443ebba
      (cpufreq: intel_pstate: Fix sysfs limits enforcement for performance
      policy) should use perf_limits instead of limits, because otherwise
      setting global limits via sysfs may affect policies inconsistently.
      
      For example, in the sequence of shell commands below, the
      scaling_min_freq attribute for policy1 and policy2 should be
      affected in the same way, because scaling_governor is set in
      the same way for both of them:
      
       # cat cpufreq/policy1/scaling_governor
       powersave
       # cat cpufreq/policy2/scaling_governor
       powersave
       # echo performance > cpufreq/policy0/scaling_governor
       # echo 94 > intel_pstate/min_perf_pct
       # cat cpufreq/policy0/scaling_min_freq
       2914000
       # cat cpufreq/policy1/scaling_min_freq
       2914000
       # cat cpufreq/policy2/scaling_min_freq
       800000
      
      The are affected differently, because intel_pstate_verify_policy()
      is invoked with limits set to &performance_limits (left behind by
      policy0) for policy1 and with limits set to &powersave_limits (left
      behind by policy1) for policy2.  Since perf_limits is set to the
      set of limits matching the policy being updated, using it instead
      of limits fixes the inconsistency.
      
      Fixes: 1443ebba (cpufreq: intel_pstate: Fix sysfs limits enforcement for performance policy)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d74b1992
    • Rafael J. Wysocki's avatar
      cpufreq: intel_pstate: Fix global settings in active mode · cd59b4be
      Rafael J. Wysocki authored
      Commit 111b8b3f (cpufreq: intel_pstate: Always keep all
      limits settings in sync) changed intel_pstate to invoke
      cpufreq_update_policy() for every registered CPU on global sysfs
      attributes updates, but that led to undesirable effects in the
      active mode if the "performance" P-state selection algorithm is
      configufred for one CPU and the "powersave" one is chosen for
      all of the other CPUs.
      
      Namely, in that case, the following is possible:
      
       # cd /sys/devices/system/cpu/
       # cat intel_pstate/max_perf_pct
       100
       # cat intel_pstate/min_perf_pct
       26
       # echo performance > cpufreq/policy0/scaling_governor
       # cat intel_pstate/max_perf_pct
       100
       # cat intel_pstate/min_perf_pct
       100
       # echo 94 > intel_pstate/min_perf_pct
       # cat intel_pstate/min_perf_pct
       26
      
      The reason why this happens is because intel_pstate attempts to
      maintain two sets of global limits in the active mode, one for
      the "performance" P-state selection algorithm and one for the
      "powersave"  P-state selection algorithm, but the P-state selection
      algorithms are set per policy, so the global limits cannot reflect
      all of them at the same time if they are different for different
      policies.
      
      In the particular situation above, the attempt to change
      min_perf_pct to 94 caused cpufreq_update_policy() to be run
      for a CPU with the "powersave"  P-state selection algorithm
      and intel_pstate_set_policy() called by it silently switched the
      global limits to the "powersave" set which finally was reflected
      by the sysfs interface.
      
      To prevent that from happening, modify intel_pstate_update_policies()
      to always switch back to the set of limits that was used right before
      it has been invoked.
      
      Fixes: 111b8b3f (cpufreq: intel_pstate: Always keep all limits settings in sync)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      cd59b4be
    • Len Brown's avatar
      cpufreq: Add the "cpufreq.off=1" cmdline option · d82f2692
      Len Brown authored
      Add the "cpufreq.off=1" cmdline option.
      
      At boot-time, this allows a user to request CONFIG_CPU_FREQ=n
      behavior from a kernel built with CONFIG_CPU_FREQ=y.
      
      This is analogous to the existing "cpuidle.off=1" option
      and CONFIG_CPU_IDLE=y
      
      This capability is valuable when we need to debug end-user
      issues in the BIOS or in Linux.  It is also convenient
      for enabling comparisons, which may otherwise require a new kernel,
      or help from BIOS SETUP, which may be buggy or unavailable.
      Signed-off-by: default avatarLen Brown <len.brown@intel.com>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d82f2692
  2. 04 Mar, 2017 3 commits
    • Rafael J. Wysocki's avatar
      cpufreq: intel_pstate: Avoid triggering cpu_frequency tracepoint unnecessarily · 64078299
      Rafael J. Wysocki authored
      In the passive mode the cpu_frequency trace event is already
      triggered by the cpufreq core or by scaling governors, so
      intel_pstate should not trigger it once again for the same
      P-state updates.
      
      In addition to that, the frequency returned by
      intel_cpufreq_fast_switch() and passed via freqs.new from
      intel_cpufreq_target() to cpufreq_freq_transition_end() should
      reflect the P-state actually set, so make that happen.
      
      Fixes: 001c76f0 (cpufreq: intel_pstate: Generic governors support)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      64078299
    • Rafael J. Wysocki's avatar
      cpufreq: intel_pstate: Fix intel_cpufreq_verify_policy() · 7f17326f
      Rafael J. Wysocki authored
      The intel_pstate_update_perf_limits() called from
      intel_cpufreq_verify_policy() may cause global P-state limits
      to change which is generally confusing and unnecessary.
      
      In the passive mode the global limits are only applied to the
      frequency selected by the scaling governor (they are not taken
      into account by governors when making decisions anyway), so making
      them follow the per-policy limits serves no purpose and may go
      against user expectations (as it generally causes the global
      attributes in sysfs to change even though they have not been
      written to in some cases).
      
      Fix that by dropping the intel_pstate_update_perf_limits()
      invocation from intel_cpufreq_verify_policy() (which also
      reduces the code size by a few lines).
      
      This change does not affect the per-CPU limits case, because those
      limits allow any P-state to be set by default in the passive mode
      and it removes the only piece of code updating them in that mode,
      so the per-policy settings will be the only ones taken into account
      in that case as expected.
      
      Fixes: 001c76f0 (cpufreq: intel_pstate: Generic governors support)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      7f17326f
    • Rafael J. Wysocki's avatar
      cpufreq: intel_pstate: Do not use performance_limits in passive mode · 2bc756e7
      Rafael J. Wysocki authored
      Using performance_limits in the passive mode doesn't make
      sense, because in that mode the global limits are applied to the
      frequency selected by the scaling governor.
      
      The maximum and minimum P-state limits in performance_limits are both
      set to 100 percent which will put all CPUs into the turbo range
      regardless of what governor is used and what frequencies are
      selected by it (that is particularly undesirable on CPUs with the
      generic powersave governor attached).
      
      For this reason, make intel_pstate_register_driver() always point
      limits to powersave_limits in the passive mode.
      
      Fixes: 001c76f0 (cpufreq: intel_pstate: Generic governors support)
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2bc756e7
  3. 28 Feb, 2017 1 commit
  4. 23 Feb, 2017 1 commit
  5. 18 Feb, 2017 1 commit
  6. 16 Feb, 2017 1 commit
  7. 15 Feb, 2017 2 commits
  8. 09 Feb, 2017 14 commits
  9. 07 Feb, 2017 1 commit
  10. 03 Feb, 2017 12 commits