1. 25 Jul, 2017 1 commit
  2. 22 Jul, 2017 1 commit
    • Viresh Kumar's avatar
      cpufreq: governor: Drop min_sampling_rate · 2d045036
      Viresh Kumar authored
      The cpufreq core and governors aren't supposed to set a limit on how
      fast we want to try changing the frequency. This is currently done for
      the legacy governors with help of min_sampling_rate.
      
      At worst, we may end up setting the sampling rate to a value lower than
      the rate at which frequency can be changed and then one of the CPUs in
      the policy will be only changing frequency for ever.
      
      But that is something for the user to decide and there is no need to
      have special handling for such cases in the core. Leave it for the user
      to figure out.
      Signed-off-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      2d045036
  3. 02 Mar, 2017 1 commit
  4. 16 Nov, 2016 1 commit
    • Stratos Karafotis's avatar
      cpufreq: conservative: Decrease frequency faster for deferred updates · 00bfe058
      Stratos Karafotis authored
      Conservative governor changes the CPU frequency in steps.
      That means that if a CPU runs at max frequency, it will need several
      sampling periods to return to min frequency when the workload
      is finished.
      
      If the update function that calculates the load and target frequency
      is deferred, the governor might need even more time to decrease the
      frequency.
      
      This may have impact to power consumption and after all conservative
      should decrease the frequency if there is no workload at every sampling
      rate.
      
      To resolve the above issue calculate the number of sampling periods
      that the update is deferred. Considering that for each sampling period
      conservative should drop the frequency by a freq_step because the
      CPU was idle apply the proper subtraction to requested frequency.
      
      Below, the kernel trace with and without this patch. First an
      intensive workload is applied on a specific CPU. Then the workload
      is removed and the CPU goes to idle.
      
      WITHOUT
      
           <idle>-0     [007] dN..   620.329153: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   620.350857: cpu_frequency: state=1700000 cpu_id=7
      kworker/7:2-556   [007] ....   620.370856: cpu_frequency: state=1900000 cpu_id=7
      kworker/7:2-556   [007] ....   620.390854: cpu_frequency: state=2100000 cpu_id=7
      kworker/7:2-556   [007] ....   620.411853: cpu_frequency: state=2200000 cpu_id=7
      kworker/7:2-556   [007] ....   620.432854: cpu_frequency: state=2400000 cpu_id=7
      kworker/7:2-556   [007] ....   620.453854: cpu_frequency: state=2600000 cpu_id=7
      kworker/7:2-556   [007] ....   620.494856: cpu_frequency: state=2900000 cpu_id=7
      kworker/7:2-556   [007] ....   620.515856: cpu_frequency: state=3100000 cpu_id=7
      kworker/7:2-556   [007] ....   620.536858: cpu_frequency: state=3300000 cpu_id=7
      kworker/7:2-556   [007] ....   620.557857: cpu_frequency: state=3401000 cpu_id=7
           <idle>-0     [007] d...   669.591363: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   669.591939: cpu_idle: state=4294967295 cpu_id=7
           <idle>-0     [007] d...   669.591980: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] dN..   669.591989: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...   670.201224: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   670.221975: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   670.222016: cpu_frequency: state=3300000 cpu_id=7
           <idle>-0     [007] d...   670.222026: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   670.234964: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...   670.801251: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   671.236046: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   671.236073: cpu_frequency: state=3100000 cpu_id=7
           <idle>-0     [007] d...   671.236112: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   671.393437: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...   671.401277: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   671.404083: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   671.404111: cpu_frequency: state=2900000 cpu_id=7
           <idle>-0     [007] d...   671.404125: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   671.404974: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...   671.501180: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   671.995414: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   671.995459: cpu_frequency: state=2800000 cpu_id=7
           <idle>-0     [007] d...   671.995469: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   671.996287: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...   672.001305: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   672.078374: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   672.078410: cpu_frequency: state=2600000 cpu_id=7
           <idle>-0     [007] d...   672.078419: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   672.158020: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   672.158040: cpu_frequency: state=2400000 cpu_id=7
           <idle>-0     [007] d...   672.158044: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   672.160038: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...   672.234557: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   672.237121: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   672.237174: cpu_frequency: state=2100000 cpu_id=7
           <idle>-0     [007] d...   672.237186: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   672.237778: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...   672.267902: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   672.269860: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   672.269906: cpu_frequency: state=1900000 cpu_id=7
           <idle>-0     [007] d...   672.269914: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   672.271902: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...   672.751342: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...   672.823056: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-556   [007] ....   672.823095: cpu_frequency: state=1600000 cpu_id=7
      
      WITH
      
           <idle>-0     [007] dN..  4380.928009: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-399   [007] ....  4380.949767: cpu_frequency: state=2000000 cpu_id=7
      kworker/7:2-399   [007] ....  4380.969765: cpu_frequency: state=2200000 cpu_id=7
      kworker/7:2-399   [007] ....  4381.009766: cpu_frequency: state=2500000 cpu_id=7
      kworker/7:2-399   [007] ....  4381.029767: cpu_frequency: state=2600000 cpu_id=7
      kworker/7:2-399   [007] ....  4381.049769: cpu_frequency: state=2800000 cpu_id=7
      kworker/7:2-399   [007] ....  4381.069769: cpu_frequency: state=3000000 cpu_id=7
      kworker/7:2-399   [007] ....  4381.089771: cpu_frequency: state=3100000 cpu_id=7
      kworker/7:2-399   [007] ....  4381.109772: cpu_frequency: state=3400000 cpu_id=7
      kworker/7:2-399   [007] ....  4381.129773: cpu_frequency: state=3401000 cpu_id=7
           <idle>-0     [007] d...  4428.226159: cpu_idle: state=1 cpu_id=7
           <idle>-0     [007] d...  4428.226176: cpu_idle: state=4294967295 cpu_id=7
           <idle>-0     [007] d...  4428.226181: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...  4428.227177: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...  4428.551640: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...  4428.649239: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-399   [007] ....  4428.649268: cpu_frequency: state=2800000 cpu_id=7
           <idle>-0     [007] d...  4428.649278: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...  4428.689856: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...  4428.799542: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...  4428.801683: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-399   [007] ....  4428.801748: cpu_frequency: state=1700000 cpu_id=7
           <idle>-0     [007] d...  4428.801761: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...  4428.806545: cpu_idle: state=4294967295 cpu_id=7
      ...
           <idle>-0     [007] d...  4429.051880: cpu_idle: state=4 cpu_id=7
           <idle>-0     [007] d...  4429.086240: cpu_idle: state=4294967295 cpu_id=7
      kworker/7:2-399   [007] ....  4429.086293: cpu_frequency: state=1600000 cpu_id=7
      
      Without the patch the CPU dropped to min frequency after 3.2s
      With the patch applied the CPU dropped to min frequency after 0.86s
      Signed-off-by: default avatarStratos Karafotis <stratosk@semaphore.gr>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      00bfe058
  5. 11 Nov, 2016 1 commit
  6. 02 Jun, 2016 2 commits
    • Rafael J. Wysocki's avatar
      cpufreq: Drop the 'initialized' field from struct cpufreq_governor · 9a15fb2c
      Rafael J. Wysocki authored
      The 'initialized' field in struct cpufreq_governor is only used by
      the conservative governor (as a usage counter) and the way that
      happens is far from straightforward and arguably incorrect.
      
      Namely, the value of 'initialized' is checked by
      cpufreq_dbs_governor_init() and cpufreq_dbs_governor_exit() and
      the results of those checks are passed (as the second argument) to
      the ->init() and ->exit() callbacks in struct dbs_governor.  Those
      callbacks are only implemented by the ondemand and conservative
      governors and ondemand doesn't use their second argument at all.
      In turn, the conservative governor uses it to decide whether or not
      to either register or unregister a transition notifier.
      
      That whole mechanism is not only unnecessarily convoluted, but also
      racy, because the 'initialized' field of struct cpufreq_governor is
      updated in cpufreq_init_governor() and cpufreq_exit_governor() under
      policy->rwsem which doesn't help if one of these functions is run
      twice in parallel for different policies (which isn't impossible in
      principle), for example.
      
      Instead of it, add a proper usage counter to the conservative
      governor and update it from cs_init() and cs_exit() which is
      guaranteed to be non-racy, as those functions are only called
      under gov_dbs_data_mutex which is global.
      
      With that in place, drop the 'initialized' field from struct
      cpufreq_governor as it is not used any more.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      9a15fb2c
    • Rafael J. Wysocki's avatar
      cpufreq: governor: Get rid of governor events · e788892b
      Rafael J. Wysocki authored
      The design of the cpufreq governor API is not very straightforward,
      as struct cpufreq_governor provides only one callback to be invoked
      from different code paths for different purposes.  The purpose it is
      invoked for is determined by its second "event" argument, causing it
      to act as a "callback multiplexer" of sorts.
      
      Unfortunately, that leads to extra complexity in governors, some of
      which implement the ->governor() callback as a switch statement
      that simply checks the event argument and invokes a separate function
      to handle that specific event.
      
      That extra complexity can be eliminated by replacing the all-purpose
      ->governor() callback with a family of callbacks to carry out specific
      governor operations: initialization and exit, start and stop and policy
      limits updates.  That also turns out to reduce the code size too, so
      do it.
      Signed-off-by: default avatarRafael J. Wysocki <rafael.j.wysocki@intel.com>
      Acked-by: default avatarViresh Kumar <viresh.kumar@linaro.org>
      e788892b
  7. 28 Apr, 2016 1 commit
  8. 01 Apr, 2016 4 commits
  9. 09 Mar, 2016 28 commits