1. 14 8月, 2017 2 次提交
  2. 02 8月, 2017 27 次提交
  3. 16 7月, 2017 1 次提交
  4. 01 7月, 2017 1 次提交
  5. 27 6月, 2017 1 次提交
    • L
      x86: use common aperfmperf_khz_on_cpu() to calculate KHz using APERF/MPERF · f8475cef
      Len Brown 提交于
      The goal of this change is to give users a uniform and meaningful
      result when they read /sys/...cpufreq/scaling_cur_freq
      on modern x86 hardware, as compared to what they get today.
      
      Modern x86 processors include the hardware needed
      to accurately calculate frequency over an interval --
      APERF, MPERF, and the TSC.
      
      Here we provide an x86 routine to make this calculation
      on supported hardware, and use it in preference to any
      driver driver-specific cpufreq_driver.get() routine.
      
      MHz is computed like so:
      
      MHz = base_MHz * delta_APERF / delta_MPERF
      
      MHz is the average frequency of the busy processor
      over a measurement interval.  The interval is
      defined to be the time between successive invocations
      of aperfmperf_khz_on_cpu(), which are expected to to
      happen on-demand when users read sysfs attribute
      cpufreq/scaling_cur_freq.
      
      As with previous methods of calculating MHz,
      idle time is excluded.
      
      base_MHz above is from TSC calibration global "cpu_khz".
      
      This x86 native method to calculate MHz returns a meaningful result
      no matter if P-states are controlled by hardware or firmware
      and/or if the Linux cpufreq sub-system is or is-not installed.
      
      When this routine is invoked more frequently, the measurement
      interval becomes shorter.  However, the code limits re-computation
      to 10ms intervals so that average frequency remains meaningful.
      
      Discerning users are encouraged to take advantage of
      the turbostat(8) utility, which can gracefully handle
      concurrent measurement intervals of arbitrary length.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      f8475cef
  6. 26 6月, 2017 2 次提交
  7. 24 6月, 2017 1 次提交
    • L
      x86: do not use cpufreq_quick_get() for /proc/cpuinfo "cpu MHz" · 51204e06
      Len Brown 提交于
      cpufreq_quick_get() allows cpufreq drivers to over-ride cpu_khz
      that is otherwise reported in x86 /proc/cpuinfo "cpu MHz".
      
      There are four problems with this scheme,
      any of them is sufficient justification to delete it.
      
       1. Depending on which cpufreq driver is loaded, the behavior
          of this field is different.
      
       2. Distros complain that they have to explain to users
          why and how this field changes.  Distros have requested a constant.
      
       3. The two major providers of this information, acpi_cpufreq
          and intel_pstate, both "get it wrong" in different ways.
      
          acpi_cpufreq lies to the user by telling them that
          they are running at whatever frequency was last
          requested by software.
      
          intel_pstate lies to the user by telling them that
          they are running at the average frequency computed
          over an undefined measurement.  But an average computed
          over an undefined interval, is itself, undefined...
      
       4. On modern processors, user space utilities, such as
          turbostat(1), are more accurate and more precise, while
          supporing concurrent measurement over arbitrary intervals.
      
      Users who have been consulting /proc/cpuinfo to
      track changing CPU frequency will be dissapointed that
      it no longer wiggles -- perhaps being unaware of the
      limitations of the information they have been consuming.
      
      Yes, they can change their scripts to look in sysfs
      cpufreq/scaling_cur_frequency.  Here they will find the same
      data of dubious quality here removed from /proc/cpuinfo.
      The value in sysfs will be addressed in a subsequent patch
      to address issues 1-3, above.
      
      Issue 4 will remain -- users that really care about
      accurate frequency information should not be using either
      proc or sysfs kernel interfaces.
      They should be using using turbostat(8), or a similar
      purpose-built analysis tool.
      Signed-off-by: NLen Brown <len.brown@intel.com>
      Reviewed-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      51204e06
  8. 22 6月, 2017 2 次提交
  9. 21 6月, 2017 1 次提交
  10. 20 6月, 2017 2 次提交