linux/drivers/cpufreq/cpufreq_conservative.c, branch v5.11-rc7

cpufreq: Register governors at core_initcall

2020-07-02T11:03:30Z

Currently, most CPUFreq governors are registered at the core_initcall time when the given governor is the default one, and the module_init time otherwise. In preparation for letting users specify the default governor on the kernel command line, change all of them to be registered at the core_initcall unconditionally, as it is already the case for the schedutil and performance governors. This will allow us to assume that builtin governors have been registered before the built-in CPUFreq drivers probe. And since all governors have similar init/exit patterns now, introduce two new macros, cpufreq_governor_{init,exit}(), to factorize the code. Acked-by: Viresh Kumar Signed-off-by: Quentin Perret Signed-off-by: Viresh Kumar [ rjw: Changelog ] Signed-off-by: Rafael J. Wysocki

cpufreq: Initialize the governors in core_initcall

2019-11-07T06:00:26Z

Initialize the cpufreq governors earlier to allow for earlier performance control during the boot process. Signed-off-by: Amit Kucheria Acked-by: Viresh Kumar Reviewed-by: Rafael J. Wysocki Signed-off-by: Daniel Lezcano Link: https://lore.kernel.org/r/b98eae9b44eb2f034d7f5d12a161f5f831be1eb7.1571656015.git.amit.kucheria@linaro.org

treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 500

2019-06-19T15:09:55Z

Based on 2 normalized pattern(s): this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation this program is free software you can redistribute it and or modify it under the terms of the gnu general public license version 2 as published by the free software foundation # extracted by the scancode license scanner the SPDX license identifier GPL-2.0-only has been chosen to replace the boilerplate/reference in 4122 file(s). Signed-off-by: Thomas Gleixner Reviewed-by: Enrico Weigelt Reviewed-by: Kate Stewart Reviewed-by: Allison Randal Cc: linux-spdx@vger.kernel.org Link: https://lkml.kernel.org/r/20190604081206.933168790@linutronix.de Signed-off-by: Greg Kroah-Hartman

cpufreq: conservative: Take limits changes into account properly

2018-10-16T10:34:45Z

If the policy limits change between invocations of cs_dbs_update(), the requested frequency value stored in dbs_info may not be updated and the function may use a stale value of it next time. Moreover, if idle periods are takem into account by cs_dbs_update(), the requested frequency value stored in dbs_info may be below the min policy limit, which is incorrect. To fix these problems, always update the requested frequency value in dbs_info along with the local copy of it when the previous requested frequency is beyond the policy limits and avoid decreasing the requested frequency below the min policy limit when taking idle periods into account. Fixes: abb6627910a1 (cpufreq: conservative: Fix next frequency selection) Fixes: 00bfe05889e9 (cpufreq: conservative: Decrease frequency faster for deferred updates) Reported-by: Waldemar Rymarkiewicz Cc: All applicable Signed-off-by: Rafael J. Wysocki Acked-by: Waldemar Rymarkiewicz Acked-by: Viresh Kumar

cpufreq: governor: Drop min_sampling_rate

2017-07-22T00:25:20Z

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: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: conservative: Allow down_threshold to take values from 1 to 10

2017-06-12T12:28:07Z

Commit 27ed3cd2ebf4 (cpufreq: conservative: Fix the logic in frequency decrease checking) removed the 10 point substraction when comparing the load against down_threshold but did not remove the related limit for the down_threshold value. As a result, down_threshold lower than 11 is not allowed even though values from 1 to 10 do work correctly too. The comment ("cannot be lower than 11 otherwise freq will not fall") also does not apply after removing the substraction. For this reason, allow down_threshold to take any value from 1 to 99 and fix the related comment. Fixes: 27ed3cd2ebf4 (cpufreq: conservative: Fix the logic in frequency decrease checking) Signed-off-by: Tomasz Wilczyński Acked-by: Viresh Kumar Cc: 3.10+ # 3.10+ Signed-off-by: Rafael J. Wysocki

cpufreq: conservative: Fix comment explaining frequency updates

2016-11-16T22:15:56Z

The original comment about the frequency increase to maximum is wrong. Both increase and decrease happen at steps. Signed-off-by: Stratos Karafotis Signed-off-by: Rafael J. Wysocki

cpufreq: conservative: Decrease frequency faster for deferred updates

2016-11-16T22:15:56Z

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 -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 -0 [007] d... 669.591363: cpu_idle: state=4 cpu_id=7 -0 [007] d... 669.591939: cpu_idle: state=4294967295 cpu_id=7 -0 [007] d... 669.591980: cpu_idle: state=4 cpu_id=7 -0 [007] dN.. 669.591989: cpu_idle: state=4294967295 cpu_id=7 ... -0 [007] d... 670.201224: cpu_idle: state=4 cpu_id=7 -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 -0 [007] d... 670.222026: cpu_idle: state=4 cpu_id=7 -0 [007] d... 670.234964: cpu_idle: state=4294967295 cpu_id=7 ... -0 [007] d... 670.801251: cpu_idle: state=4 cpu_id=7 -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 -0 [007] d... 671.236112: cpu_idle: state=4 cpu_id=7 -0 [007] d... 671.393437: cpu_idle: state=4294967295 cpu_id=7 ... -0 [007] d... 671.401277: cpu_idle: state=4 cpu_id=7 -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 -0 [007] d... 671.404125: cpu_idle: state=4 cpu_id=7 -0 [007] d... 671.404974: cpu_idle: state=4294967295 cpu_id=7 ... -0 [007] d... 671.501180: cpu_idle: state=4 cpu_id=7 -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 -0 [007] d... 671.995469: cpu_idle: state=4 cpu_id=7 -0 [007] d... 671.996287: cpu_idle: state=4294967295 cpu_id=7 ... -0 [007] d... 672.001305: cpu_idle: state=4 cpu_id=7 -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 -0 [007] d... 672.078419: cpu_idle: state=4 cpu_id=7 -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 -0 [007] d... 672.158044: cpu_idle: state=4 cpu_id=7 -0 [007] d... 672.160038: cpu_idle: state=4294967295 cpu_id=7 ... -0 [007] d... 672.234557: cpu_idle: state=4 cpu_id=7 -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 -0 [007] d... 672.237186: cpu_idle: state=4 cpu_id=7 -0 [007] d... 672.237778: cpu_idle: state=4294967295 cpu_id=7 ... -0 [007] d... 672.267902: cpu_idle: state=4 cpu_id=7 -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 -0 [007] d... 672.269914: cpu_idle: state=4 cpu_id=7 -0 [007] d... 672.271902: cpu_idle: state=4294967295 cpu_id=7 ... -0 [007] d... 672.751342: cpu_idle: state=4 cpu_id=7 -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 -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 -0 [007] d... 4428.226159: cpu_idle: state=1 cpu_id=7 -0 [007] d... 4428.226176: cpu_idle: state=4294967295 cpu_id=7 -0 [007] d... 4428.226181: cpu_idle: state=4 cpu_id=7 -0 [007] d... 4428.227177: cpu_idle: state=4294967295 cpu_id=7 ... -0 [007] d... 4428.551640: cpu_idle: state=4 cpu_id=7 -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 -0 [007] d... 4428.649278: cpu_idle: state=4 cpu_id=7 -0 [007] d... 4428.689856: cpu_idle: state=4294967295 cpu_id=7 ... -0 [007] d... 4428.799542: cpu_idle: state=4 cpu_id=7 -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 -0 [007] d... 4428.801761: cpu_idle: state=4 cpu_id=7 -0 [007] d... 4428.806545: cpu_idle: state=4294967295 cpu_id=7 ... -0 [007] d... 4429.051880: cpu_idle: state=4 cpu_id=7 -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: Stratos Karafotis Acked-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: conservative: Rename get_freq_target() to get_freq_step()

2016-11-14T20:34:52Z

What's returned from this function is the delta by which the frequency must be increased or decreased and not the final frequency that should be selected. Name it properly to match its purpose. Also update the variables used to store that value. Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki

cpufreq: governor: Don't use 'timer' keyword

2016-11-11T00:48:33Z

The earlier implementation of governors used background timers and so functions, mutex, etc had 'timer' keyword in their names. But that's not true anymore. Replace 'timer' with 'update', as those functions, variables are based around updates to frequency. Signed-off-by: Viresh Kumar Signed-off-by: Rafael J. Wysocki