mbox series

[v4,0/5] Refactor thermal pressure update to avoid code duplication

Message ID 20211109195714.7750-1-lukasz.luba@arm.com (mailing list archive)
Headers show
Series Refactor thermal pressure update to avoid code duplication | expand

Message

Lukasz Luba Nov. 9, 2021, 7:57 p.m. UTC
Hi all,

This patch set v4 aims to refactor the thermal pressure update
code. There are already two clients which do similar thing:
convert the capped frequency value into the capacity of
affected CPU and call the 'set' function to store the 
reduced capacity into the per-cpu variable.
There might be more than two of these users. In near future
it will be scmi-cpufreq driver, which receives notification
from FW about reduced frequency due to thermal. Other vendors
might follow. Let's avoid code duplication and potential
conversion bugs. Move the conversion code into the arch_topology.c
where the capacity calculation setup code and thermal pressure sit.

Apart from that $subject patches, there is one patch (3/5) which fixes
issue in qcom-cpufreq-hw.c when the thermal pressure is not 
updated for offline CPUs. It's similar fix that has been merged
recently for cpufreq_cooling.c:
2ad8ccc17d1e4270cf65a3f2

The patch 4/5 fixes also qcom-cpufreq-hw.c driver code which did
the translation from frequency to capacity wrongly when there
was a boost frequency available and stored in 'policy->cpuinfo.max_freq'.

Changes:
v4:
- remove the warning when boost frequency is passed and set thermal
  pressure to 0 in that case, which means the capping is totally removed
  (issue reported by Steev)
- remove the check from patch 4/5 with
  'throttled_freq > policy->cpuinfo.max_freq' since it doesn't have
  effect; instead relay on new arch_update_thermal_pressure() handling
  correctly such use case; this would also fix an issue in that original
  driver code, where the reduced capacity was calculated wrongly due
  to 'policy->cpuinfo.max_freq' used as a divider
- adjusted comments stressing the fact that the boost frequencies are
  supported
v3 [3]:
- added warning and check if provided capped frequency is lower than
  max (Viresh)
- removed check for empty cpu mask (Viresh)
- replaced tabs with spaces in the doxygen comment (Viresh)
- renamed {arch|topology}_thermal_pressure_update() to
  {arch|topology}_update_thermal_pressure() so it's align with scheme (Dietmar)
- added info about MHz in freq_factor into patch description (Dietmar)
v2 [2]:
- added Reviewed-by from Thara for patch 3/5
- changed the doxygen comment and used mult_frac()
  according to Thara's suggestion in patch 1/5
v1 -> [1]

Regards,
Lukasz Luba

[1] https://lore.kernel.org/linux-pm/20211007080729.8262-1-lukasz.luba@arm.com/
[2] https://lore.kernel.org/linux-pm/20211015144550.23719-1-lukasz.luba@arm.com/
[3] https://lore.kernel.org/linux-pm/20211103161020.26714-1-lukasz.luba@arm.com/

Lukasz Luba (5):
  arch_topology: Introduce thermal pressure update function
  thermal: cpufreq_cooling: Use new thermal pressure update function
  cpufreq: qcom-cpufreq-hw: Update offline CPUs per-cpu thermal pressure
  cpufreq: qcom-cpufreq-hw: Use new thermal pressure update function
  arch_topology: Remove unused topology_set_thermal_pressure() and
    related

 arch/arm/include/asm/topology.h   |  2 +-
 arch/arm64/include/asm/topology.h |  2 +-
 drivers/base/arch_topology.c      | 42 ++++++++++++++++++++++++++++---
 drivers/cpufreq/qcom-cpufreq-hw.c | 14 +++--------
 drivers/thermal/cpufreq_cooling.c |  6 +----
 include/linux/arch_topology.h     |  4 +--
 include/linux/sched/topology.h    |  6 ++---
 init/Kconfig                      |  2 +-
 8 files changed, 50 insertions(+), 28 deletions(-)

Comments

Viresh Kumar Nov. 11, 2021, 3:15 a.m. UTC | #1
On 09-11-21, 19:57, Lukasz Luba wrote:
> Hi all,
> 
> This patch set v4 aims to refactor the thermal pressure update
> code. There are already two clients which do similar thing:
> convert the capped frequency value into the capacity of
> affected CPU and call the 'set' function to store the 
> reduced capacity into the per-cpu variable.
> There might be more than two of these users. In near future
> it will be scmi-cpufreq driver, which receives notification
> from FW about reduced frequency due to thermal. Other vendors
> might follow. Let's avoid code duplication and potential
> conversion bugs. Move the conversion code into the arch_topology.c
> where the capacity calculation setup code and thermal pressure sit.
> 
> Apart from that $subject patches, there is one patch (3/5) which fixes
> issue in qcom-cpufreq-hw.c when the thermal pressure is not 
> updated for offline CPUs. It's similar fix that has been merged
> recently for cpufreq_cooling.c:
> 2ad8ccc17d1e4270cf65a3f2
> 
> The patch 4/5 fixes also qcom-cpufreq-hw.c driver code which did
> the translation from frequency to capacity wrongly when there
> was a boost frequency available and stored in 'policy->cpuinfo.max_freq'.

LGTM. I will apply this in a few days so people get time to Ack/Review
the patches.
Lukasz Luba Nov. 23, 2021, 9:11 a.m. UTC | #2
Hi Viresh,

On 11/11/21 3:15 AM, Viresh Kumar wrote:
> On 09-11-21, 19:57, Lukasz Luba wrote:
>> Hi all,
>>
>> This patch set v4 aims to refactor the thermal pressure update
>> code. There are already two clients which do similar thing:
>> convert the capped frequency value into the capacity of
>> affected CPU and call the 'set' function to store the
>> reduced capacity into the per-cpu variable.
>> There might be more than two of these users. In near future
>> it will be scmi-cpufreq driver, which receives notification
>> from FW about reduced frequency due to thermal. Other vendors
>> might follow. Let's avoid code duplication and potential
>> conversion bugs. Move the conversion code into the arch_topology.c
>> where the capacity calculation setup code and thermal pressure sit.
>>
>> Apart from that $subject patches, there is one patch (3/5) which fixes
>> issue in qcom-cpufreq-hw.c when the thermal pressure is not
>> updated for offline CPUs. It's similar fix that has been merged
>> recently for cpufreq_cooling.c:
>> 2ad8ccc17d1e4270cf65a3f2
>>
>> The patch 4/5 fixes also qcom-cpufreq-hw.c driver code which did
>> the translation from frequency to capacity wrongly when there
>> was a boost frequency available and stored in 'policy->cpuinfo.max_freq'.
> 
> LGTM. I will apply this in a few days so people get time to Ack/Review
> the patches.
> 

Thara has reviewed the patches. Could you take the patch set into
your tree, please?
Viresh Kumar Nov. 23, 2021, 9:45 a.m. UTC | #3
On 09-11-21, 19:57, Lukasz Luba wrote:
> Hi all,
> 
> This patch set v4 aims to refactor the thermal pressure update
> code. There are already two clients which do similar thing:
> convert the capped frequency value into the capacity of
> affected CPU and call the 'set' function to store the 
> reduced capacity into the per-cpu variable.
> There might be more than two of these users. In near future
> it will be scmi-cpufreq driver, which receives notification
> from FW about reduced frequency due to thermal. Other vendors
> might follow. Let's avoid code duplication and potential
> conversion bugs. Move the conversion code into the arch_topology.c
> where the capacity calculation setup code and thermal pressure sit.
> 
> Apart from that $subject patches, there is one patch (3/5) which fixes
> issue in qcom-cpufreq-hw.c when the thermal pressure is not 
> updated for offline CPUs. It's similar fix that has been merged
> recently for cpufreq_cooling.c:
> 2ad8ccc17d1e4270cf65a3f2
> 
> The patch 4/5 fixes also qcom-cpufreq-hw.c driver code which did
> the translation from frequency to capacity wrongly when there
> was a boost frequency available and stored in 'policy->cpuinfo.max_freq'.
> 
> Changes:
> v4:
> - remove the warning when boost frequency is passed and set thermal
>   pressure to 0 in that case, which means the capping is totally removed
>   (issue reported by Steev)
> - remove the check from patch 4/5 with
>   'throttled_freq > policy->cpuinfo.max_freq' since it doesn't have
>   effect; instead relay on new arch_update_thermal_pressure() handling
>   correctly such use case; this would also fix an issue in that original
>   driver code, where the reduced capacity was calculated wrongly due
>   to 'policy->cpuinfo.max_freq' used as a divider
> - adjusted comments stressing the fact that the boost frequencies are
>   supported

> Lukasz Luba (5):
>   arch_topology: Introduce thermal pressure update function
>   thermal: cpufreq_cooling: Use new thermal pressure update function
>   cpufreq: qcom-cpufreq-hw: Update offline CPUs per-cpu thermal pressure
>   cpufreq: qcom-cpufreq-hw: Use new thermal pressure update function
>   arch_topology: Remove unused topology_set_thermal_pressure() and
>     related
> 
>  arch/arm/include/asm/topology.h   |  2 +-
>  arch/arm64/include/asm/topology.h |  2 +-
>  drivers/base/arch_topology.c      | 42 ++++++++++++++++++++++++++++---
>  drivers/cpufreq/qcom-cpufreq-hw.c | 14 +++--------
>  drivers/thermal/cpufreq_cooling.c |  6 +----
>  include/linux/arch_topology.h     |  4 +--
>  include/linux/sched/topology.h    |  6 ++---
>  init/Kconfig                      |  2 +-
>  8 files changed, 50 insertions(+), 28 deletions(-)

Applied. Thanks.
Lukasz Luba Nov. 23, 2021, 9:46 a.m. UTC | #4
On 11/23/21 9:45 AM, Viresh Kumar wrote:
> On 09-11-21, 19:57, Lukasz Luba wrote:
>> Hi all,
>>
>> This patch set v4 aims to refactor the thermal pressure update
>> code. There are already two clients which do similar thing:
>> convert the capped frequency value into the capacity of
>> affected CPU and call the 'set' function to store the
>> reduced capacity into the per-cpu variable.
>> There might be more than two of these users. In near future
>> it will be scmi-cpufreq driver, which receives notification
>> from FW about reduced frequency due to thermal. Other vendors
>> might follow. Let's avoid code duplication and potential
>> conversion bugs. Move the conversion code into the arch_topology.c
>> where the capacity calculation setup code and thermal pressure sit.
>>
>> Apart from that $subject patches, there is one patch (3/5) which fixes
>> issue in qcom-cpufreq-hw.c when the thermal pressure is not
>> updated for offline CPUs. It's similar fix that has been merged
>> recently for cpufreq_cooling.c:
>> 2ad8ccc17d1e4270cf65a3f2
>>
>> The patch 4/5 fixes also qcom-cpufreq-hw.c driver code which did
>> the translation from frequency to capacity wrongly when there
>> was a boost frequency available and stored in 'policy->cpuinfo.max_freq'.
>>
>> Changes:
>> v4:
>> - remove the warning when boost frequency is passed and set thermal
>>    pressure to 0 in that case, which means the capping is totally removed
>>    (issue reported by Steev)
>> - remove the check from patch 4/5 with
>>    'throttled_freq > policy->cpuinfo.max_freq' since it doesn't have
>>    effect; instead relay on new arch_update_thermal_pressure() handling
>>    correctly such use case; this would also fix an issue in that original
>>    driver code, where the reduced capacity was calculated wrongly due
>>    to 'policy->cpuinfo.max_freq' used as a divider
>> - adjusted comments stressing the fact that the boost frequencies are
>>    supported
> 
>> Lukasz Luba (5):
>>    arch_topology: Introduce thermal pressure update function
>>    thermal: cpufreq_cooling: Use new thermal pressure update function
>>    cpufreq: qcom-cpufreq-hw: Update offline CPUs per-cpu thermal pressure
>>    cpufreq: qcom-cpufreq-hw: Use new thermal pressure update function
>>    arch_topology: Remove unused topology_set_thermal_pressure() and
>>      related
>>
>>   arch/arm/include/asm/topology.h   |  2 +-
>>   arch/arm64/include/asm/topology.h |  2 +-
>>   drivers/base/arch_topology.c      | 42 ++++++++++++++++++++++++++++---
>>   drivers/cpufreq/qcom-cpufreq-hw.c | 14 +++--------
>>   drivers/thermal/cpufreq_cooling.c |  6 +----
>>   include/linux/arch_topology.h     |  4 +--
>>   include/linux/sched/topology.h    |  6 ++---
>>   init/Kconfig                      |  2 +-
>>   8 files changed, 50 insertions(+), 28 deletions(-)
> 
> Applied. Thanks.
> 

Thank you!