Revision tags: v6.6.25, v6.6.24, v6.6.23, v6.6.16, v6.6.15, v6.6.14, v6.6.13, v6.6.12, v6.6.11, v6.6.10, v6.6.9, v6.6.8, v6.6.7, v6.6.6, v6.6.5, v6.6.4, v6.6.3, v6.6.2, v6.5.11, v6.6.1, v6.5.10, v6.6, v6.5.9, v6.5.8, v6.5.7, v6.5.6, v6.5.5, v6.5.4, v6.5.3, v6.5.2, v6.1.51, v6.5.1, v6.1.50, v6.5, v6.1.49, v6.1.48, v6.1.46, v6.1.45, v6.1.44, v6.1.43, v6.1.42, v6.1.41, v6.1.40, v6.1.39, v6.1.38, v6.1.37, v6.1.36, v6.4, v6.1.35, v6.1.34, v6.1.33, v6.1.32, v6.1.31, v6.1.30, v6.1.29, v6.1.28, v6.1.27, v6.1.26, v6.3, v6.1.25, v6.1.24, v6.1.23, v6.1.22, v6.1.21, v6.1.20, v6.1.19, v6.1.18, v6.1.17, v6.1.16 |
|
#
32a7a021 |
| 07-Mar-2023 |
Daniel Lezcano <daniel.lezcano@linaro.org> |
thermal/core: Relocate the traces definition in thermal directory
The traces are exported but only local to the thermal core code. On the other side, the traces take the thermal zone device structur
thermal/core: Relocate the traces definition in thermal directory
The traces are exported but only local to the thermal core code. On the other side, the traces take the thermal zone device structure as argument, thus they have to rely on the exported thermal.h header file. As we want to move the structure to the private thermal core header, first we have to relocate those traces to the same place as many drivers do.
Cc: Steven Rostedt <rostedt@goodmis.org> Suggested-by: Steven Rostedt <rostedt@goodmis.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Steven Rostedt (Google) <rostedt@goodmis.org> Link: https://lore.kernel.org/r/20230307133735.90772-2-daniel.lezcano@linaro.org
show more ...
|
#
86df7d19 |
| 10-Mar-2023 |
Rob Herring <robh@kernel.org> |
thermal: Use of_property_present() for testing DT property presence
It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_prope
thermal: Use of_property_present() for testing DT property presence
It is preferred to use typed property access functions (i.e. of_property_read_<type> functions) rather than low-level of_get_property/of_find_property functions for reading properties. As part of this, convert of_get_property/of_find_property calls to the recently added of_property_present() helper when we just want to test for presence of a property and nothing more.
Signed-off-by: Rob Herring <robh@kernel.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v6.1.15, v6.1.14, v6.1.13, v6.2, v6.1.12, v6.1.11, v6.1.10, v6.1.9, v6.1.8, v6.1.7, v6.1.6, v6.1.5, v6.0.19, v6.0.18, v6.1.4, v6.1.3, v6.0.17, v6.1.2, v6.0.16, v6.1.1, v6.0.15, v6.0.14, v6.0.13, v6.1, v6.0.12, v6.0.11, v6.0.10, v5.15.80, v6.0.9, v5.15.79, v6.0.8, v5.15.78, v6.0.7, v5.15.77, v5.15.76, v6.0.6, v6.0.5, v5.15.75, v6.0.4, v6.0.3, v6.0.2, v5.15.74, v5.15.73, v6.0.1, v5.15.72, v6.0, v5.15.71, v5.15.70, v5.15.69, v5.15.68, v5.15.67, v5.15.66, v5.15.65, v5.15.64 |
|
#
cff89527 |
| 25-Aug-2022 |
Xuewen Yan <xuewen.yan@unisoc.com> |
thermal: cpufreq_cooling: Check the policy first in cpufreq_cooling_register()
Since the policy needs to be accessed first when obtaining cpu devices, first check whether the policy is legal before
thermal: cpufreq_cooling: Check the policy first in cpufreq_cooling_register()
Since the policy needs to be accessed first when obtaining cpu devices, first check whether the policy is legal before this.
Fixes: 5130802ddbb1 ("thermal: cpu_cooling: Switch to QoS requests for freq limits") Signed-off-by: Xuewen Yan <xuewen.yan@unisoc.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.15.63 |
|
#
96f1c529 |
| 22-Aug-2022 |
Jilin Yuan <yuanjilin@cdjrlc.com> |
thermal: Drop duplicate words from comments
Drop duplicate words from two kerneldoc comments in the thermal subsystem.
Signed-off-by: Jilin Yuan <yuanjilin@cdjrlc.com> [ rjw: Subject edits and chan
thermal: Drop duplicate words from comments
Drop duplicate words from two kerneldoc comments in the thermal subsystem.
Signed-off-by: Jilin Yuan <yuanjilin@cdjrlc.com> [ rjw: Subject edits and changelog rewrite ] Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.15.62, v5.15.61, v5.15.60, v5.15.59, v5.19, v5.15.58, v5.15.57, v5.15.56, v5.15.55, v5.15.54, v5.15.53, v5.15.52, v5.15.51, v5.15.50, v5.15.49, v5.15.48, v5.15.47 |
|
#
9784d2fb |
| 13-Jun-2022 |
Lukasz Luba <lukasz.luba@arm.com> |
drivers/thermal/cpufreq_cooling: Update outdated comments
The code has moved and left some comments stale. Update them where there is a need.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed
drivers/thermal/cpufreq_cooling: Update outdated comments
The code has moved and left some comments stale. Update them where there is a need.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://lore.kernel.org/r/20220613124327.30766-4-lukasz.luba@arm.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
show more ...
|
#
3f7ced7a |
| 13-Jun-2022 |
Lukasz Luba <lukasz.luba@arm.com> |
drivers/thermal/cpufreq_cooling : Refactor thermal_power_cpu_get_power tracing
Simplify the thermal_power_cpu_get_power trace event by removing complicated cpumask and variable length array. Now the
drivers/thermal/cpufreq_cooling : Refactor thermal_power_cpu_get_power tracing
Simplify the thermal_power_cpu_get_power trace event by removing complicated cpumask and variable length array. Now the tools parsing trace output don't have to hassle to get this power data. The simplified format version uses 'policy->cpu'. Remove also the 'load' information completely since there is very little value of it in this trace event. To get the CPUs' load (or utilization) there are other dedicated trace hooks in the kernel. This patch also simplifies and speeds-up the main cooling code when that trace event is enabled.
Rename the trace event to avoid confusion of tools which parse the trace file.
Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://lore.kernel.org/r/20220613124327.30766-3-lukasz.luba@arm.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
show more ...
|
#
3cbf6a8a |
| 13-Jun-2022 |
Lukasz Luba <lukasz.luba@arm.com> |
drivers/thermal/cpufreq_cooling: Use private callback ops for each cooling device
It is very unlikely that one CPU cluster would have the EM and some other won't have it (because EM registration fai
drivers/thermal/cpufreq_cooling: Use private callback ops for each cooling device
It is very unlikely that one CPU cluster would have the EM and some other won't have it (because EM registration failed or DT lacks needed entry). Although, we should avoid modifying global variable with callbacks anyway. Redesign this and add safety for such situation.
Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://lore.kernel.org/r/20220613124327.30766-2-lukasz.luba@arm.com Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
show more ...
|
#
ae6ccaa6 |
| 07-Jul-2022 |
Lukasz Luba <lukasz.luba@arm.com> |
PM: EM: convert power field to micro-Watts precision and align drivers
The milli-Watts precision causes rounding errors while calculating efficiency cost for each OPP. This is especially visible in
PM: EM: convert power field to micro-Watts precision and align drivers
The milli-Watts precision causes rounding errors while calculating efficiency cost for each OPP. This is especially visible in the 'simple' Energy Model (EM), where the power for each OPP is provided from OPP framework. This can cause some OPPs to be marked inefficient, while using micro-Watts precision that might not happen.
Update all EM users which access 'power' field and assume the value is in milli-Watts.
Solve also an issue with potential overflow in calculation of energy estimation on 32bit machine. It's needed now since the power value (thus the 'cost' as well) are higher.
Example calculation which shows the rounding error and impact:
power = 'dyn-power-coeff' * volt_mV * volt_mV * freq_MHz
power_a_uW = (100 * 600mW * 600mW * 500MHz) / 10^6 = 18000 power_a_mW = (100 * 600mW * 600mW * 500MHz) / 10^9 = 18
power_b_uW = (100 * 605mW * 605mW * 600MHz) / 10^6 = 21961 power_b_mW = (100 * 605mW * 605mW * 600MHz) / 10^9 = 21
max_freq = 2000MHz
cost_a_mW = 18 * 2000MHz/500MHz = 72 cost_a_uW = 18000 * 2000MHz/500MHz = 72000
cost_b_mW = 21 * 2000MHz/600MHz = 70 // <- artificially better cost_b_uW = 21961 * 2000MHz/600MHz = 73203
The 'cost_b_mW' (which is based on old milli-Watts) is misleadingly better that the 'cost_b_uW' (this patch uses micro-Watts) and such would have impact on the 'inefficient OPPs' information in the Cpufreq framework. This patch set removes the rounding issue.
Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
#
bb447999 |
| 21-Jun-2022 |
Dietmar Eggemann <dietmar.eggemann@arm.com> |
sched, drivers: Remove max param from effective_cpu_util()/sched_cpu_util()
effective_cpu_util() already has a `int cpu' parameter which allows to retrieve the CPU capacity scale factor (or maximum
sched, drivers: Remove max param from effective_cpu_util()/sched_cpu_util()
effective_cpu_util() already has a `int cpu' parameter which allows to retrieve the CPU capacity scale factor (or maximum CPU capacity) inside this function via an arch_scale_cpu_capacity(cpu).
A lot of code calling effective_cpu_util() (or the shim sched_cpu_util()) needs the maximum CPU capacity, i.e. it will call arch_scale_cpu_capacity() already. But not having to pass it into effective_cpu_util() will make the EAS wake-up code easier, especially when the maximum CPU capacity reduced by the thermal pressure is passed through the EAS wake-up functions.
Due to the asymmetric CPU capacity support of arm/arm64 architectures, arch_scale_cpu_capacity(int cpu) is a per-CPU variable read access via per_cpu(cpu_scale, cpu) on such a system. On all other architectures it is a a compile-time constant (SCHED_CAPACITY_SCALE).
Signed-off-by: Dietmar Eggemann <dietmar.eggemann@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Vincent Guittot <vincent.guittot@linaro.org> Tested-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://lkml.kernel.org/r/20220621090414.433602-4-vdonnefort@google.com
show more ...
|
Revision tags: v5.15.46, v5.15.45, v5.15.44, v5.15.43, v5.15.42, v5.18, v5.15.41, v5.15.40, v5.15.39, v5.15.38, v5.15.37, v5.15.36, v5.15.35, v5.15.34, v5.15.33, v5.15.32, v5.15.31 |
|
#
9926bbec |
| 21-Mar-2022 |
Lukasz Luba <lukasz.luba@arm.com> |
thermal: cooling: Check Energy Model type in cpufreq_cooling and devfreq_cooling
The Energy Model can now be artificial, which means the power values are mathematically generated to leverage EAS whi
thermal: cooling: Check Energy Model type in cpufreq_cooling and devfreq_cooling
The Energy Model can now be artificial, which means the power values are mathematically generated to leverage EAS while not expected to be on an uniform scale with other devices providing power information. If this EM type is in use, the thermal governor IPA should not be allowed to operate, since the relation between cooling devices is not properly defined. Thus, it might be possible that big GPU has lower power values than a Little CPU. To mitigate a misbehaviour of the thermal control algorithm, simply do not register the cooling device as IPA's power actor.
Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Ionela Voinescu <ionela.voinescu@arm.com> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
show more ...
|
Revision tags: v5.17, v5.15.30, v5.15.29, v5.15.28, v5.15.27, v5.15.26, v5.15.25, v5.15.24, v5.15.23, v5.15.22, v5.15.21, v5.15.20, v5.15.19, v5.15.18, v5.15.17, v5.4.173, v5.15.16, v5.15.15, v5.16, v5.15.10, v5.15.9, v5.15.8, v5.15.7, v5.15.6, v5.15.5, v5.15.4, v5.15.3, v5.15.2 |
|
#
5168b1be |
| 09-Nov-2021 |
Lukasz Luba <lukasz.luba@arm.com> |
thermal: cpufreq_cooling: Use new thermal pressure update function
Thermal pressure provides a new API, which allows to use CPU frequency as an argument. That removes the need of local conversion to
thermal: cpufreq_cooling: Use new thermal pressure update function
Thermal pressure provides a new API, which allows to use CPU frequency as an argument. That removes the need of local conversion to capacity. Use this new function and remove old conversion code.
Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
show more ...
|
#
91fafd22 |
| 25-Aug-2022 |
Xuewen Yan <xuewen.yan@unisoc.com> |
thermal: cpufreq_cooling: Check the policy first in cpufreq_cooling_register()
[ Upstream commit cff895277c8558221ba180aefe26799dcb4eec86 ]
Since the policy needs to be accessed first when obtainin
thermal: cpufreq_cooling: Check the policy first in cpufreq_cooling_register()
[ Upstream commit cff895277c8558221ba180aefe26799dcb4eec86 ]
Since the policy needs to be accessed first when obtaining cpu devices, first check whether the policy is legal before this.
Fixes: 5130802ddbb1 ("thermal: cpu_cooling: Switch to QoS requests for freq limits") Signed-off-by: Xuewen Yan <xuewen.yan@unisoc.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
Revision tags: v5.15.1, v5.15, v5.14.14, v5.14.13, v5.14.12, v5.14.11, v5.14.10, v5.14.9, v5.14.8, v5.14.7, v5.14.6, v5.10.67, v5.10.66, v5.14.5, v5.14.4, v5.10.65, v5.14.3, v5.10.64, v5.14.2, v5.10.63, v5.14.1, v5.10.62, v5.14, v5.10.61, v5.10.60, v5.10.53, v5.10.52, v5.10.51, v5.10.50, v5.10.49, v5.13, v5.10.46 |
|
#
2ad8ccc1 |
| 14-Jun-2021 |
Lukasz Luba <lukasz.luba@arm.com> |
thermal/cpufreq_cooling: Update offline CPUs per-cpu thermal_pressure
The thermal pressure signal gives information to the scheduler about reduced CPU capacity due to thermal. It is based on a value
thermal/cpufreq_cooling: Update offline CPUs per-cpu thermal_pressure
The thermal pressure signal gives information to the scheduler about reduced CPU capacity due to thermal. It is based on a value stored in a per-cpu 'thermal_pressure' variable. The online CPUs will get the new value there, while the offline won't. Unfortunately, when the CPU is back online, the value read from per-cpu variable might be wrong (stale data). This might affect the scheduler decisions, since it sees the CPU capacity differently than what is actually available.
Fix it by making sure that all online+offline CPUs would get the proper value in their per-cpu variable when thermal framework sets capping.
Fixes: f12e4f66ab6a3 ("thermal/cpu-cooling: Update thermal pressure in case of a maximum frequency capping") Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://lore.kernel.org/r/20210614191030.22241-1-lukasz.luba@arm.com
show more ...
|
Revision tags: v5.10.43, v5.10.42, v5.10.41, v5.10.40, v5.10.39, v5.4.119, v5.10.36, v5.10.35, v5.10.34, v5.4.116, v5.10.33, v5.12, v5.10.32, v5.10.31, v5.10.30, v5.10.27, v5.10.26, v5.10.25, v5.10.24, v5.10.23, v5.10.22, v5.10.21, v5.10.20, v5.10.19, v5.4.101, v5.10.18, v5.10.17, v5.11, v5.10.16, v5.10.15, v5.10.14 |
|
#
34ab17cc |
| 28-Dec-2020 |
brian-sy yang <brian-sy.yang@mediatek.com> |
thermal/drivers/cpufreq_cooling: Fix slab OOB issue
Slab OOB issue is scanned by KASAN in cpu_power_to_freq(). If power is limited below the power of OPP0 in EM table, it will cause slab out-of-boun
thermal/drivers/cpufreq_cooling: Fix slab OOB issue
Slab OOB issue is scanned by KASAN in cpu_power_to_freq(). If power is limited below the power of OPP0 in EM table, it will cause slab out-of-bound issue with negative array index.
Return the lowest frequency if limited power cannot found a suitable OPP in EM table to fix this issue.
Backtrace: [<ffffffd02d2a37f0>] die+0x104/0x5ac [<ffffffd02d2a5630>] bug_handler+0x64/0xd0 [<ffffffd02d288ce4>] brk_handler+0x160/0x258 [<ffffffd02d281e5c>] do_debug_exception+0x248/0x3f0 [<ffffffd02d284488>] el1_dbg+0x14/0xbc [<ffffffd02d75d1d4>] __kasan_report+0x1dc/0x1e0 [<ffffffd02d75c2e0>] kasan_report+0x10/0x20 [<ffffffd02d75def8>] __asan_report_load8_noabort+0x18/0x28 [<ffffffd02e6fce5c>] cpufreq_power2state+0x180/0x43c [<ffffffd02e6ead80>] power_actor_set_power+0x114/0x1d4 [<ffffffd02e6fac24>] allocate_power+0xaec/0xde0 [<ffffffd02e6f9f80>] power_allocator_throttle+0x3ec/0x5a4 [<ffffffd02e6ea888>] handle_thermal_trip+0x160/0x294 [<ffffffd02e6edd08>] thermal_zone_device_check+0xe4/0x154 [<ffffffd02d351cb4>] process_one_work+0x5e4/0xe28 [<ffffffd02d352f44>] worker_thread+0xa4c/0xfac [<ffffffd02d360124>] kthread+0x33c/0x358 [<ffffffd02d289940>] ret_from_fork+0xc/0x18
Fixes: 371a3bc79c11b ("thermal/drivers/cpufreq_cooling: Fix wrong frequency converted from power") Signed-off-by: brian-sy yang <brian-sy.yang@mediatek.com> Signed-off-by: Michael Kao <michael.kao@mediatek.com> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Cc: stable@vger.kernel.org #v5.7 Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20201229050831.19493-1-michael.kao@mediatek.com
show more ...
|
#
87602aeb |
| 14-Mar-2021 |
Daniel Lezcano <daniel.lezcano@linaro.org> |
thermal/drivers/cpufreq_cooling: Remove unused list
There is a list with the purpose of grouping the cpufreq cooling device together as described in the comments but actually it is unused, the code
thermal/drivers/cpufreq_cooling: Remove unused list
There is a list with the purpose of grouping the cpufreq cooling device together as described in the comments but actually it is unused, the code evolved since 2012 and the list was no longer needed.
Delete the remaining unused list related code.
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://lore.kernel.org/r/20210314111333.16551-5-daniel.lezcano@linaro.org
show more ...
|
#
ef37d1f9 |
| 14-Mar-2021 |
Daniel Lezcano <daniel.lezcano@linaro.org> |
thermal/drivers/cpufreq_cooling: Use device name instead of auto-numbering
Currently the naming of a cooling device is just a cooling technique followed by a number. When there are multiple cooling
thermal/drivers/cpufreq_cooling: Use device name instead of auto-numbering
Currently the naming of a cooling device is just a cooling technique followed by a number. When there are multiple cooling devices using the same technique, it is impossible to clearly identify the related device as this one is just a number.
For instance:
thermal-cpufreq-0 thermal-cpufreq-1 etc ...
The 'thermal' prefix is redundant with the subsystem namespace. This patch removes the 'thermal' prefix and changes the number by the device name. So the naming above becomes:
cpufreq-cpu0 cpufreq-cpu4 etc ...
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://lore.kernel.org/r/20210314111333.16551-2-daniel.lezcano@linaro.org
show more ...
|
#
a51afb13 |
| 16-Feb-2021 |
Viresh Kumar <viresh.kumar@linaro.org> |
thermal: cpufreq_cooling: freq_qos_update_request() returns < 0 on error
freq_qos_update_request() returns 1 if the effective constraint value has changed, 0 if the effective constraint value has no
thermal: cpufreq_cooling: freq_qos_update_request() returns < 0 on error
freq_qos_update_request() returns 1 if the effective constraint value has changed, 0 if the effective constraint value has not changed, or a negative error code on failures.
The frequency constraints for CPUs can be set by different parts of the kernel. If the maximum frequency constraint set by other parts of the kernel are set at a lower value than the one corresponding to cooling state 0, then we will never be able to cool down the system as freq_qos_update_request() will keep on returning 0 and we will skip updating cpufreq_state and thermal pressure.
Fix that by doing the updates even in the case where freq_qos_update_request() returns 0, as we have effectively set the constraint to a new value even if the consolidated value of the actual constraint is unchanged because of external factors.
Cc: v5.7+ <stable@vger.kernel.org> # v5.7+ Reported-by: Thara Gopinath <thara.gopinath@linaro.org> Fixes: f12e4f66ab6a ("thermal/cpu-cooling: Update thermal pressure in case of a maximum frequency capping") Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Tested-by: Lukasz Luba <lukasz.luba@arm.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Thara Gopinath<thara.gopinath@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/b2b7e84944937390256669df5a48ce5abba0c1ef.1613540713.git.viresh.kumar@linaro.org
show more ...
|
Revision tags: v5.10 |
|
#
d1515851 |
| 07-Dec-2020 |
Viresh Kumar <viresh.kumar@linaro.org> |
thermal: cpufreq_cooling: Reuse sched_cpu_util() for SMP platforms
Several parts of the kernel are already using the effective CPU utilization (as seen by the scheduler) to get the current load on t
thermal: cpufreq_cooling: Reuse sched_cpu_util() for SMP platforms
Several parts of the kernel are already using the effective CPU utilization (as seen by the scheduler) to get the current load on the CPU, do the same here instead of depending on the idle time of the CPU, which isn't that accurate comparatively.
This is also the right thing to do as it makes the cpufreq governor (schedutil) align better with the cpufreq_cooling driver, as the power requested by cpufreq_cooling governor will exactly match the next frequency requested by the schedutil governor since they are both using the same metric to calculate load.
This was tested on ARM Hikey6220 platform with hackbench, sysbench and schbench. None of them showed any regression or significant improvements. Schbench is the most important ones out of these as it creates the scenario where the utilization numbers provide a better estimate of the future.
Scenario 1: The CPUs were mostly idle in the previous polling window of the IPA governor as the tasks were sleeping and here are the details from traces (load is in %):
Old: thermal_power_cpu_get_power: cpus=00000000,000000ff freq=1200000 total_load=203 load={{0x35,0x1,0x0,0x31,0x0,0x0,0x64,0x0}} dynamic_power=1339 New: thermal_power_cpu_get_power: cpus=00000000,000000ff freq=1200000 total_load=600 load={{0x60,0x46,0x45,0x45,0x48,0x3b,0x61,0x44}} dynamic_power=3960
Here, the "Old" line gives the load and requested_power (dynamic_power here) numbers calculated using the idle time based implementation, while "New" is based on the CPU utilization from scheduler.
As can be clearly seen, the load and requested_power numbers are simply incorrect in the idle time based approach and the numbers collected from CPU's utilization are much closer to the reality.
Scenario 2: The CPUs were busy in the previous polling window of the IPA governor:
Old: thermal_power_cpu_get_power: cpus=00000000,000000ff freq=1200000 total_load=800 load={{0x64,0x64,0x64,0x64,0x64,0x64,0x64,0x64}} dynamic_power=5280 New: thermal_power_cpu_get_power: cpus=00000000,000000ff freq=1200000 total_load=708 load={{0x4d,0x5c,0x5c,0x5b,0x5c,0x5c,0x51,0x5b}} dynamic_power=4672
As can be seen, the idle time based load is 100% for all the CPUs as it took only the last window into account, but in reality the CPUs aren't that loaded as shown by the utilization numbers.
Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Link: https://lkml.kernel.org/r/9c255c83d78d58451abc06848001faef94c87a12.1607400596.git.viresh.kumar@linaro.org
show more ...
|
#
236761f1 |
| 06-Nov-2020 |
Zhuguangqing <zhuguangqing@xiaomi.com> |
thermal/drivers/cpufreq_cooling: Update cpufreq_state only if state has changed
If state has not changed successfully and we updated cpufreq_state, next time when the new state is equal to cpufreq_s
thermal/drivers/cpufreq_cooling: Update cpufreq_state only if state has changed
If state has not changed successfully and we updated cpufreq_state, next time when the new state is equal to cpufreq_state (not changed successfully last time), we will return directly and miss a freq_qos_update_request() that should have been.
Fixes: 5130802ddbb1 ("thermal: cpu_cooling: Switch to QoS requests for freq limits") Cc: v5.4+ <stable@vger.kernel.org> # v5.4+ Signed-off-by: Zhuguangqing <zhuguangqing@xiaomi.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20201106092243.15574-1-zhuguangqing83@gmail.com
show more ...
|
#
f2b24004 |
| 14-Jun-2021 |
Lukasz Luba <lukasz.luba@arm.com> |
thermal/cpufreq_cooling: Update offline CPUs per-cpu thermal_pressure
[ Upstream commit 2ad8ccc17d1e4270cf65a3f2a07a7534aa23e3fb ]
The thermal pressure signal gives information to the scheduler abo
thermal/cpufreq_cooling: Update offline CPUs per-cpu thermal_pressure
[ Upstream commit 2ad8ccc17d1e4270cf65a3f2a07a7534aa23e3fb ]
The thermal pressure signal gives information to the scheduler about reduced CPU capacity due to thermal. It is based on a value stored in a per-cpu 'thermal_pressure' variable. The online CPUs will get the new value there, while the offline won't. Unfortunately, when the CPU is back online, the value read from per-cpu variable might be wrong (stale data). This might affect the scheduler decisions, since it sees the CPU capacity differently than what is actually available.
Fix it by making sure that all online+offline CPUs would get the proper value in their per-cpu variable when thermal framework sets capping.
Fixes: f12e4f66ab6a3 ("thermal/cpu-cooling: Update thermal pressure in case of a maximum frequency capping") Signed-off-by: Lukasz Luba <lukasz.luba@arm.com> Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Link: https://lore.kernel.org/r/20210614191030.22241-1-lukasz.luba@arm.com Signed-off-by: Sasha Levin <sashal@kernel.org>
show more ...
|
#
c24a2091 |
| 28-Dec-2020 |
brian-sy yang <brian-sy.yang@mediatek.com> |
thermal/drivers/cpufreq_cooling: Fix slab OOB issue
commit 34ab17cc6c2c1ac93d7e5d53bb972df9a968f085 upstream.
Slab OOB issue is scanned by KASAN in cpu_power_to_freq(). If power is limited below th
thermal/drivers/cpufreq_cooling: Fix slab OOB issue
commit 34ab17cc6c2c1ac93d7e5d53bb972df9a968f085 upstream.
Slab OOB issue is scanned by KASAN in cpu_power_to_freq(). If power is limited below the power of OPP0 in EM table, it will cause slab out-of-bound issue with negative array index.
Return the lowest frequency if limited power cannot found a suitable OPP in EM table to fix this issue.
Backtrace: [<ffffffd02d2a37f0>] die+0x104/0x5ac [<ffffffd02d2a5630>] bug_handler+0x64/0xd0 [<ffffffd02d288ce4>] brk_handler+0x160/0x258 [<ffffffd02d281e5c>] do_debug_exception+0x248/0x3f0 [<ffffffd02d284488>] el1_dbg+0x14/0xbc [<ffffffd02d75d1d4>] __kasan_report+0x1dc/0x1e0 [<ffffffd02d75c2e0>] kasan_report+0x10/0x20 [<ffffffd02d75def8>] __asan_report_load8_noabort+0x18/0x28 [<ffffffd02e6fce5c>] cpufreq_power2state+0x180/0x43c [<ffffffd02e6ead80>] power_actor_set_power+0x114/0x1d4 [<ffffffd02e6fac24>] allocate_power+0xaec/0xde0 [<ffffffd02e6f9f80>] power_allocator_throttle+0x3ec/0x5a4 [<ffffffd02e6ea888>] handle_thermal_trip+0x160/0x294 [<ffffffd02e6edd08>] thermal_zone_device_check+0xe4/0x154 [<ffffffd02d351cb4>] process_one_work+0x5e4/0xe28 [<ffffffd02d352f44>] worker_thread+0xa4c/0xfac [<ffffffd02d360124>] kthread+0x33c/0x358 [<ffffffd02d289940>] ret_from_fork+0xc/0x18
Fixes: 371a3bc79c11b ("thermal/drivers/cpufreq_cooling: Fix wrong frequency converted from power") Signed-off-by: brian-sy yang <brian-sy.yang@mediatek.com> Signed-off-by: Michael Kao <michael.kao@mediatek.com> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Cc: stable@vger.kernel.org #v5.7 Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20201229050831.19493-1-michael.kao@mediatek.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
b3df1eac |
| 16-Feb-2021 |
Viresh Kumar <viresh.kumar@linaro.org> |
thermal: cpufreq_cooling: freq_qos_update_request() returns < 0 on error
commit a51afb13311cd85b2f638c691b2734622277d8f5 upstream.
freq_qos_update_request() returns 1 if the effective constraint va
thermal: cpufreq_cooling: freq_qos_update_request() returns < 0 on error
commit a51afb13311cd85b2f638c691b2734622277d8f5 upstream.
freq_qos_update_request() returns 1 if the effective constraint value has changed, 0 if the effective constraint value has not changed, or a negative error code on failures.
The frequency constraints for CPUs can be set by different parts of the kernel. If the maximum frequency constraint set by other parts of the kernel are set at a lower value than the one corresponding to cooling state 0, then we will never be able to cool down the system as freq_qos_update_request() will keep on returning 0 and we will skip updating cpufreq_state and thermal pressure.
Fix that by doing the updates even in the case where freq_qos_update_request() returns 0, as we have effectively set the constraint to a new value even if the consolidated value of the actual constraint is unchanged because of external factors.
Cc: v5.7+ <stable@vger.kernel.org> # v5.7+ Reported-by: Thara Gopinath <thara.gopinath@linaro.org> Fixes: f12e4f66ab6a ("thermal/cpu-cooling: Update thermal pressure in case of a maximum frequency capping") Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Lukasz Luba <lukasz.luba@arm.com> Tested-by: Lukasz Luba <lukasz.luba@arm.com> Reviewed-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> Tested-by: Thara Gopinath<thara.gopinath@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/b2b7e84944937390256669df5a48ce5abba0c1ef.1613540713.git.viresh.kumar@linaro.org Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
#
b98ce1a1 |
| 06-Nov-2020 |
Zhuguangqing <zhuguangqing@xiaomi.com> |
thermal/drivers/cpufreq_cooling: Update cpufreq_state only if state has changed
commit 236761f19a4f373354f1dcf399b57753f1f4b871 upstream.
If state has not changed successfully and we updated cpufre
thermal/drivers/cpufreq_cooling: Update cpufreq_state only if state has changed
commit 236761f19a4f373354f1dcf399b57753f1f4b871 upstream.
If state has not changed successfully and we updated cpufreq_state, next time when the new state is equal to cpufreq_state (not changed successfully last time), we will return directly and miss a freq_qos_update_request() that should have been.
Fixes: 5130802ddbb1 ("thermal: cpu_cooling: Switch to QoS requests for freq limits") Cc: v5.4+ <stable@vger.kernel.org> # v5.4+ Signed-off-by: Zhuguangqing <zhuguangqing@xiaomi.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20201106092243.15574-1-zhuguangqing83@gmail.com Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
show more ...
|
Revision tags: v5.8.17, v5.8.16, v5.8.15, v5.9, v5.8.14, v5.8.13, v5.8.12, v5.8.11, v5.8.10 |
|
#
ecd1d2a3 |
| 14-Sep-2020 |
zhuguangqing <zhuguangqing@xiaomi.com> |
thermal: cooling: Remove unused variable *tz
1. devfreq_cooling.c: The variable *tz is not used in devfreq_cooling_get_requested_power(), devfreq_cooling_state2power() and devfreq_cooling_power2stat
thermal: cooling: Remove unused variable *tz
1. devfreq_cooling.c: The variable *tz is not used in devfreq_cooling_get_requested_power(), devfreq_cooling_state2power() and devfreq_cooling_power2state().
2. cpufreq_cooling.c: After 84fe2cab48590, the variable *tz is not used anymore in cpufreq_get_requested_power(), cpufreq_state2power() and cpufreq_power2state().
Remove the variable *tz.
Signed-off-by: zhuguangqing <zhuguangqing@xiaomi.com> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200914071101.13575-1-zhuguangqing83@gmail.com
show more ...
|
Revision tags: v5.8.9, v5.8.8, v5.8.7, v5.8.6, v5.4.62, v5.8.5, v5.8.4, v5.4.61, v5.8.3, v5.4.60, v5.8.2, v5.4.59, v5.8.1, v5.4.58, v5.4.57, v5.4.56, v5.8, v5.7.12, v5.4.55, v5.7.11, v5.4.54, v5.7.10, v5.4.53, v5.4.52, v5.7.9, v5.7.8, v5.4.51, v5.4.50, v5.7.7, v5.4.49, v5.7.6, v5.7.5, v5.4.48 |
|
#
371a3bc7 |
| 19-Jun-2020 |
Finley Xiao <finley.xiao@rock-chips.com> |
thermal/drivers/cpufreq_cooling: Fix wrong frequency converted from power
The function cpu_power_to_freq is used to find a frequency and set the cooling device to consume at most the power to be con
thermal/drivers/cpufreq_cooling: Fix wrong frequency converted from power
The function cpu_power_to_freq is used to find a frequency and set the cooling device to consume at most the power to be converted. For example, if the power to be converted is 80mW, and the em table is as follow. struct em_cap_state table[] = { /* KHz mW */ { 1008000, 36, 0 }, { 1200000, 49, 0 }, { 1296000, 59, 0 }, { 1416000, 72, 0 }, { 1512000, 86, 0 }, }; The target frequency should be 1416000KHz, not 1512000KHz.
Fixes: 349d39dc5739 ("thermal: cpu_cooling: merge frequency and power tables") Cc: <stable@vger.kernel.org> # v4.13+ Signed-off-by: Finley Xiao <finley.xiao@rock-chips.com> Acked-by: Viresh Kumar <viresh.kumar@linaro.org> Reviewed-by: Amit Kucheria <amit.kucheria@linaro.org> Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org> Link: https://lore.kernel.org/r/20200619090825.32747-1-finley.xiao@rock-chips.com
show more ...
|