1. 18 5月, 2016 4 次提交
  2. 12 5月, 2016 6 次提交
  3. 11 5月, 2016 2 次提交
    • A
      cpufreq: powernv: del_timer_sync when global and local pstate are equal · 0bc10b93
      Akshay Adiga 提交于
      When global and local pstate are equal in a powernv_target_index() call,
      we don't queue a timer. But we may have timer already queued for future.
      This could cause the timer to fire one additional time for no use.
      Signed-off-by: NAkshay Adiga <akshay.adiga@linux.vnet.ibm.com>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      0bc10b93
    • A
      cpufreq: powernv: Move smp_call_function_any() out of irq safe block · 1fd3ff28
      Akshay Adiga 提交于
      Fix a WARN_ON caused by smp_call_function_any() when irq is disabled,
      because of changes made in the patch ('cpufreq: powernv: Ramp-down
       global pstate slower than local-pstate')
      https://patchwork.ozlabs.org/patch/612058/
      
       WARNING: CPU: 0 PID: 4 at kernel/smp.c:291
      smp_call_function_single+0x170/0x180
      
       Call Trace:
       [c0000007f648f9f0] [c0000007f648fa90] 0xc0000007f648fa90 (unreliable)
       [c0000007f648fa30] [c0000000001430e0] smp_call_function_any+0x170/0x1c0
       [c0000007f648fa90] [c0000000007b4b00]
      powernv_cpufreq_target_index+0xe0/0x250
       [c0000007f648fb00] [c0000000007ac9dc]
      __cpufreq_driver_target+0x20c/0x3d0
       [c0000007f648fbc0] [c0000000007b1b4c] od_dbs_timer+0xcc/0x260
       [c0000007f648fc10] [c0000000007b3024] dbs_work_handler+0x54/0xa0
       [c0000007f648fc50] [c0000000000c49a8] process_one_work+0x1d8/0x590
       [c0000007f648fce0] [c0000000000c4e08] worker_thread+0xa8/0x660
       [c0000007f648fd80] [c0000000000cca88] kthread+0x108/0x130
       [c0000007f648fe30] [c0000000000095e8] ret_from_kernel_thread+0x5c/0x74
      
      - Calling smp_call_function_any() with interrupt disabled (through
       spin_lock_irqsave) could cause a deadlock, as smp_call_function_any()
       relies on the IPI to complete. This is detected in the
       smp_call_function_any() call and hence the WARN_ON.
      
      - As the spinlock (gpstates->lock) is only used to synchronize access of
       global_pstate_info  between timer irq handler and target_index calls. And
       the timer irq handler just try_locks() hence it would not cause a
       deadlock. Hence could do without making spinlocks irq safe.
      
      - As the smp_call_function_any() is a blocking call and does not access
       global_pstates_info, it could reduce the critcal section by moving
       smp_call_function_any() after giving up the lock.
      Reported-by: NAbdul Haleem <abdhalee@linux.vnet.linux.com>
      Signed-off-by: NAkshay Adiga <akshay.adiga@linux.vnet.ibm.com>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1fd3ff28
  4. 10 5月, 2016 1 次提交
  5. 09 5月, 2016 1 次提交
  6. 07 5月, 2016 2 次提交
  7. 06 5月, 2016 1 次提交
    • R
      cpufreq: governor: Fix handling of special cases in dbs_update() · 9485e4ca
      Rafael J. Wysocki 提交于
      As reported in KBZ 69821:
      
      "With CONFIG_HZ_PERIODIC=y cpu stays at the lowest frequcency 800MHz
       even if usage goes to 100%, frequency does not scale up, the governor
       in use is ondemand. Neither works conservative. Performance and
       userspace governors work as expected.
      
       With CONFIG_NO_HZ_IDLE or CONFIG_NO_HZ_FULL cpu scales up with ondemand
       as expected."
      
      Analysis carried out by Chen Yu leads to the conclusion that the
      observed issue is due to idle_time in dbs_update() representing a
      negative number in which case the function will return 0 as the load
      (unless load is greater than 0 for another CPU sharing the policy),
      although that need not be the right choice.
      
      Indeed, idle_time representing a negative number means that during
      the last sampling interval the CPU was almost 100% busy on the rough
      average, so 100 should be returned as the load in that case.
      
      Modify the code accordingly and rearrange it to clarify the handling
      of all of the special cases in it.  While at it, also avoid returning
      zero as the load if time_elapsed is 0 (it doesn't really make sense
      to return 0 then).
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=69821Tested-by: NChen Yu <yu.c.chen@intel.com>
      Tested-by: NTimo Valtoaho <timo.valtoaho@gmail.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      9485e4ca
  8. 05 5月, 2016 7 次提交
  9. 04 5月, 2016 1 次提交
    • R
      intel_pstate: Fix intel_pstate_get() · 6d45b719
      Rafael J. Wysocki 提交于
      After commit 8fa520af "intel_pstate: Remove freq calculation from
      intel_pstate_calc_busy()" intel_pstate_get() calls get_avg_frequency()
      to compute the average frequency, which is problematic for two reasons.
      
      First, intel_pstate_get() may be invoked before the driver reads the
      CPU feedback registers for the first time and if that happens,
      get_avg_frequency() will attempt to divide by zero.
      
      Second, the get_avg_frequency() call in intel_pstate_get() is racy
      with respect to intel_pstate_sample() and it may end up returning
      completely meaningless values for this reason.
      
      Moreover, after commit 7349ec04 "intel_pstate: Move
      intel_pstate_calc_busy() into get_target_pstate_use_performance()"
      sample.core_pct_busy is never computed on Atom, but it is used in
      intel_pstate_adjust_busy_pstate() in that case too.
      
      To address those problems notice that if sample.core_pct_busy
      was used in the average frequency computation carried out by
      get_avg_frequency(), both the divide by zero problem and the
      race with respect to intel_pstate_sample() would be avoided.
      
      Accordingly, move the invocation of intel_pstate_calc_busy() from
      get_target_pstate_use_performance() to intel_pstate_update_util(),
      which also will take care of the uninitialized sample.core_pct_busy
      on Atom, and modify get_avg_frequency() to use sample.core_pct_busy
      as per the above.
      Reported-by: Nkernel test robot <ying.huang@linux.intel.com>
      Link: http://marc.info/?l=linux-kernel&m=146226437623173&w=4
      Fixes: 8fa520af "intel_pstate: Remove freq calculation from intel_pstate_calc_busy()"
      Fixes: 7349ec04 "intel_pstate: Move intel_pstate_calc_busy() into get_target_pstate_use_performance()"
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      6d45b719
  10. 02 5月, 2016 1 次提交
  11. 28 4月, 2016 14 次提交
    • S
      cpufreq: st: enable selective initialization based on the platform · 2482bc31
      Sudeep Holla 提交于
      The sti-cpufreq does unconditional registration of the cpufreq-dt driver
      which causes issue on an multi-platform build. For example, on Vexpress
      TC2 platform, we get the following error on boot:
      
      cpu cpu0: OPP-v2 not supported
      cpu cpu0: Not doing voltage scaling
      cpu: dev_pm_opp_of_cpumask_add_table: couldn't find opp table
      	for cpu:0, -19
      cpu cpu0: dev_pm_opp_get_max_volt_latency: Invalid regulator (-6)
      ...
      arm_big_little: bL_cpufreq_register: Failed registering platform driver:
      		vexpress-spc, err: -17
      
      The actual driver fails to initialise as cpufreq-dt is probed
      successfully, which is incorrect. This issue can happen to any platform
      not using cpufreq-dt in a multi-platform build.
      
      This patch adds a check to do selective initialization of the driver.
      
      Fixes: ab0ea257 (cpufreq: st: Provide runtime initialised driver for ST's platforms)
      Signed-off-by: NSudeep Holla <sudeep.holla@arm.com>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: NLee Jones <lee.jones@linaro.org>
      Cc: 4.5+ <stable@vger.kernel.org> # 4.5+
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2482bc31
    • V
      cpufreq: mvebu: Move cpufreq code into drivers/cpufreq/ · 9f123def
      Viresh Kumar 提交于
      Move cpufreq bits for mvebu into drivers/cpufreq/ directory, that's
      where they really belong to.
      
      Compiled tested only.
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9f123def
    • V
      cpufreq: dt: Kill platform-data · eb96924a
      Viresh Kumar 提交于
      There are no more users of platform-data for cpufreq-dt driver, get rid
      of it.
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Reviewed-by: NStephen Boyd <sboyd@codeaurora.org>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      eb96924a
    • V
      mvebu: Use dev_pm_opp_set_sharing_cpus() to mark OPP tables as shared · 947bd567
      Viresh Kumar 提交于
      That will allow us to avoid using cpufreq-dt platform data.
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      947bd567
    • V
      cpufreq: dt: Identify cpu-sharing for platforms without operating-points-v2 · 1530b996
      Viresh Kumar 提交于
      Existing platforms, which do not support operating-points-v2, can
      explicitly tell the opp core that some of the CPUs share opp tables,
      with help of dev_pm_opp_set_sharing_cpus().
      
      For such platforms, explicitly ask the opp core to provide list of CPUs
      sharing the opp table with current cpu device, before falling back to
      platform data.
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      1530b996
    • R
      Merge back earlier cpufreq material for v4.7. · 29c5e7b2
      Rafael J. Wysocki 提交于
      29c5e7b2
    • V
      PM / OPP: Add dev_pm_opp_get_sharing_cpus() · 6f707daa
      Viresh Kumar 提交于
      OPP core allows a platform to mark OPP table as shared, when the
      platform isn't using operating-points-v2 bindings.
      
      And, so there should be a non DT way of finding out if the OPP table is
      shared or not.
      
      This patch adds dev_pm_opp_get_sharing_cpus(), which first tries to get
      OPP sharing information from the opp-table (in case it is already marked
      as shared), otherwise it uses the existing DT way of finding sharing
      information.
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      6f707daa
    • V
      PM / OPP: Mark cpumask as const in dev_pm_opp_set_sharing_cpus() · dde370b2
      Viresh Kumar 提交于
      dev_pm_opp_set_sharing_cpus() isn't supposed to update the cpumask
      passed as its parameter, and so it should always have been marked
      'const'.
      
      Do it now.
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      dde370b2
    • V
      PM / OPP: -ENOSYS is applicable only to syscalls · d708b384
      Viresh Kumar 提交于
      Some of the routines have used -ENOSYS for the cases where the
      functionality isn't implemented in the kernel. But ENOSYS is supposed to
      be used only for syscalls.
      
      Replace that with -ENOTSUPP, which specifically means that the operation
      isn't supported.
      
      While at it, replace exiting -EINVAL errors for similar cases to
      -ENOTSUPP.
      Signed-off-by: NViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: NArnd Bergmann <arnd@arndb.de>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      d708b384
    • R
      cpufreq: governor: Change confusing struct field and variable names · b4f4b4b3
      Rafael J. Wysocki 提交于
      The name of the prev_cpu_wall field in struct cpu_dbs_info is
      confusing, because it doesn't represent wall time, but the previous
      update time as returned by get_cpu_idle_time() (that may be the
      current value of jiffies_64 in some cases, for example).
      
      Moreover, the names of some related variables in dbs_update() take
      that confusion further.
      
      Rename all of those things to make their names reflect the purpose
      more accurately.  While at it, drop unnecessary parens from one of
      the updated expressions.
      
      No functional changes.
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Acked-by: NChen Yu <yu.c.chen@intel.com>
      b4f4b4b3
    • S
      cpufreq: intel_pstate: Enable PPC enforcement for servers · 2b3ec765
      Srinivas Pandruvada 提交于
      For platforms which are controlled via remove node manager, enable _PPC by
      default. These platforms are mostly categorized as enterprise server or
      performance servers. These platforms needs to go through some
      certifications tests, which tests control via _PPC.
      The relative risk of enabling by default is  low as this is is less likely
      that these systems have broken _PSS table.
      Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2b3ec765
    • S
      cpufreq: intel_pstate: Adjust policy->max · 3be9200d
      Srinivas Pandruvada 提交于
      When policy->max is changed via _PPC or sysfs and is more than the max non
      turbo frequency, it does not really change resulting performance in some
      processors. When policy->max results in a P-State ratio more than the
      turbo activation ratio, then processor can choose any P-State up to max
      turbo. So the user or _PPC setting has no value, but this can cause
      undesirable side effects like:
      - Showing reduced max percentage in Intel P-State sysfs
      - It can cause reduced max performance under certain boundary conditions:
      The requested max scaling frequency either via _PPC or via cpufreq-sysfs,
      will be converted into a fixed floating point max percent scale. In
      majority of the cases this will result in correct max. But not 100% of the
      time. If the _PPC is requested at a point where the calculation lead to a
      lower max, this can result in a lower P-State then expected and it will
      impact performance.
      Example of this condition using a Broadwell laptop with config TDP.
      
      ACPI _PSS table from a Broadwell laptop
      2301000 2300000 2200000 2000000 1900000 1800000 1700000 1500000 1400000
      1300000 1100000 1000000 900000 800000 600000 500000
      
      The actual results by disabling config TDP so that we can get what is
      requested on or below 2300000Khz.
      
      scaling_max_freq        Max Requested P-State   Resultant scaling
      max
      ---------------------------------------- ----------------------
      2400000                 18                      2900000 (max
      turbo)
      2300000                 17                      2300000 (max
      physical non turbo)
      2200000                 15                      2100000
      2100000                 15                      2100000
      2000000                 13                      1900000
      1900000                 13                      1900000
      1800000                 12                      1800000
      1700000                 11                      1700000
      1600000                 10                      1600000
      1500000                 f                       1500000
      1400000                 e                       1400000
      1300000                 d                       1300000
      1200000                 c                       1200000
      1100000                 a                       1000000
      1000000                 a                       1000000
      900000                  9                        900000
      800000                  8                        800000
      700000                  7                        700000
      600000                  6                        600000
      500000                  5                        500000
      ------------------------------------------------------------------
      
      Now set the config TDP level 1 ratio as 0x0b (equivalent to 1100000KHz)
      in BIOS (not every system will let you adjust this).
      The turbo activation ratio will be set to one less than that, which will
      be 0x0a (So any request above 1000000KHz should result in turbo region
      assuming no thermal limits).
      Here _PPC will request max to 1100000KHz (which basically should still
      result in turbo as this is more than the turbo activation ratio up to
      max allowable turbo frequency), but actual calculation resulted in a max
      ceiling P-State which is 0x0a. So under any load condition, this driver
      will not request turbo P-States. This will be a huge performance hit.
      
      When config TDP feature is ON, if the _PPC points to a frequency above
      turbo activation ratio, the performance can still reach max turbo. In this
      case we don't need to treat this as the reduced frequency in set_policy
      callback.
      
      In this change when config TDP is active (by checking if the physical max
      non turbo ratio is more than the current max non turbo ratio), any request
      above current max non turbo is treated as full performance.
      Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      [ rjw : Minor cleanups ]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      3be9200d
    • S
      cpufreq: intel_pstate: Enforce _PPC limits · 9522a2ff
      Srinivas Pandruvada 提交于
      Use ACPI _PPC notification to limit max P state driver will request.
      ACPI _PPC change notification is sent by BIOS to limit max P state
      in several cases:
      - Reduce impact of platform thermal condition
      - When Config TDP feature is used, a changed _PPC is sent to
      follow TDP change
      - Remote node managers in server want to control platform power
      via baseboard management controller (BMC)
      
      This change registers with ACPI processor performance lib so that
      _PPC changes are notified to cpufreq core, which in turns will
      result in call to .setpolicy() callback. Also the way _PSS
      table identifies a turbo frequency is not compatible to max turbo
      frequency in intel_pstate, so the very first entry in _PSS needs
      to be adjusted.
      
      This feature can be turned on by using kernel parameters:
      intel_pstate=support_acpi_ppc
      Signed-off-by: NSrinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
      [ rjw: Minor cleanups ]
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      9522a2ff
    • A
      cpufreq: powernv: Ramp-down global pstate slower than local-pstate · eaa2c3ae
      Akshay Adiga 提交于
      The frequency transition latency from pmin to pmax is observed to be in
      few millisecond granurality. And it usually happens to take a performance
      penalty during sudden frequency rampup requests.
      
      This patch set solves this problem by using an entity called "global
      pstates". The global pstate is a Chip-level entity, so the global entitiy
      (Voltage) is managed across the cores. The local pstate is a Core-level
      entity, so the local entity (frequency) is managed across threads.
      
      This patch brings down global pstate at a slower rate than the local
      pstate. Hence by holding global pstates higher than local pstate makes
      the subsequent rampups faster.
      
      A per policy structure is maintained to keep track of the global and
      local pstate changes. The global pstate is brought down using a parabolic
      equation. The ramp down time to pmin is set to ~5 seconds. To make sure
      that the global pstates are dropped at regular interval , a timer is
      queued for every 2 seconds during ramp-down phase, which eventually brings
      the pstate down to local pstate.
      
      Iozone results show fairly consistent performance boost.
      YCSB on redis shows improved Max latencies in most cases.
      
      Iozone write/rewite test were made with filesizes 200704Kb and 401408Kb
      with different record sizes . The following table shows IOoperations/sec
      with and without patch.
      
      Iozone Results ( in op/sec) ( mean over 3 iterations )
      ---------------------------------------------------------------------
      file size-                      with            without		  %
      recordsize-IOtype               patch           patch		change
      ----------------------------------------------------------------------
      200704-1-SeqWrite               1616532         1615425         0.06
      200704-1-Rewrite                2423195         2303130         5.21
      200704-2-SeqWrite               1628577         1602620         1.61
      200704-2-Rewrite                2428264         2312154         5.02
      200704-4-SeqWrite               1617605         1617182         0.02
      200704-4-Rewrite                2430524         2351238         3.37
      200704-8-SeqWrite               1629478         1600436         1.81
      200704-8-Rewrite                2415308e         2298136         5.09
      200704-16-SeqWrite              1619632         1618250         0.08
      200704-16-Rewrite               2396650         2352591         1.87
      200704-32-SeqWrite              1632544         1598083         2.15
      200704-32-Rewrite               2425119         2329743         4.09
      200704-64-SeqWrite              1617812         1617235         0.03
      200704-64-Rewrite               2402021         2321080         3.48
      200704-128-SeqWrite             1631998         1600256         1.98
      200704-128-Rewrite              2422389         2304954         5.09
      200704-256 SeqWrite             1617065         1616962         0.00
      200704-256-Rewrite              2432539         2301980         5.67
      200704-512-SeqWrite             1632599         1598656         2.12
      200704-512-Rewrite              2429270         2323676         4.54
      200704-1024-SeqWrite            1618758         1616156         0.16
      200704-1024-Rewrite             2431631         2315889         4.99
      401408-1-SeqWrite               1631479         1608132         1.45
      401408-1-Rewrite                2501550         2459409         1.71
      401408-2-SeqWrite               1617095         1626069         -0.55
      401408-2-Rewrite                2507557         2443621         2.61
      401408-4-SeqWrite               1629601         1611869         1.10
      401408-4-Rewrite                2505909         2462098         1.77
      401408-8-SeqWrite               1617110         1626968         -0.60
      401408-8-Rewrite                2512244         2456827         2.25
      401408-16-SeqWrite              1632609         1609603         1.42
      401408-16-Rewrite               2500792         2451405         2.01
      401408-32-SeqWrite              1619294         1628167         -0.54
      401408-32-Rewrite               2510115         2451292         2.39
      401408-64-SeqWrite              1632709         1603746         1.80
      401408-64-Rewrite               2506692         2433186         3.02
      401408-128-SeqWrite             1619284         1627461         -0.50
      401408-128-Rewrite              2518698         2453361         2.66
      401408-256-SeqWrite             1634022         1610681         1.44
      401408-256-Rewrite              2509987         2446328         2.60
      401408-512-SeqWrite             1617524         1628016         -0.64
      401408-512-Rewrite              2504409         2442899         2.51
      401408-1024-SeqWrite            1629812         1611566         1.13
      401408-1024-Rewrite             2507620          2442968        2.64
      
      Tested with YCSB workload (50% update + 50% read) over redis for 1 million
      records and 1 million operation. Each test was carried out with target
      operations per second and persistence disabled.
      
      Max-latency (in us)( mean over 5 iterations )
      ---------------------------------------------------------------
      op/s    Operation       with patch      without patch   %change
      ---------------------------------------------------------------
      15000   Read            61480.6         50261.4         22.32
      15000   cleanup         215.2           293.6           -26.70
      15000   update          25666.2         25163.8         2.00
      
      25000   Read            32626.2         89525.4         -63.56
      25000   cleanup         292.2           263.0           11.10
      25000   update          32293.4         90255.0         -64.22
      
      35000   Read            34783.0         33119.0         5.02
      35000   cleanup         321.2           395.8           -18.8
      35000   update          36047.0         38747.8         -6.97
      
      40000   Read            38562.2         42357.4         -8.96
      40000   cleanup         371.8           384.6           -3.33
      40000   update          27861.4         41547.8         -32.94
      
      45000   Read            42271.0         88120.6         -52.03
      45000   cleanup         263.6           383.0           -31.17
      45000   update          29755.8         81359.0         -63.43
      
      (test without target op/s)
      47659   Read            83061.4         136440.6        -39.12
      47659   cleanup         195.8           193.8           1.03
      47659   update          73429.4         124971.8        -41.24
      Signed-off-by: NAkshay Adiga <akshay.adiga@linux.vnet.ibm.com>
      Reviewed-by: NGautham R. Shenoy <ego@linux.vnet.ibm.com>
      Acked-by: NViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: NRafael J. Wysocki <rafael.j.wysocki@intel.com>
      eaa2c3ae