linux-kernel - Re: [Patch 2/2] ACPI: processor: Add support to configure CPUFREQ reduction pctg

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <fe4e1458-c39a-339c-c7b0-1dfff8ed5c30@nvidia.com>
Date:   Thu, 24 Aug 2023 18:48:01 +0530
From:   Sumit Gupta <sumitg@...dia.com>
To:     "Rafael J. Wysocki" <rafael@...nel.org>
CC:     <rui.zhang@...el.com>, <lenb@...nel.org>, <treding@...dia.com>,
        <jonathanh@...dia.com>, <linux-acpi@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>, <sanjayc@...dia.com>,
        <ksitaraman@...dia.com>, <srikars@...dia.com>,
        <jbrasen@...dia.com>, <bbasu@...dia.com>,
        Sumit Gupta <sumitg@...dia.com>
Subject: Re: [Patch 2/2] ACPI: processor: Add support to configure CPUFREQ
 reduction pctg


>>>>
>>>> Add support to configure the CPUFREQ reduction percentage and set the
>>>> maximum number of throttling steps accordingly. Current implementation
>>>> of processor_thermal performs software throttling in fixed steps of
>>>> "20%" which can be too coarse for some platforms. Change that by adding
>>>> new config to provide the reduction percentage.
>>>>
>>>> Signed-off-by: Srikar Srimath Tirumala <srikars@...dia.com>
>>>> Signed-off-by: Sumit Gupta <sumitg@...dia.com>
>>>> ---
>>>>    drivers/acpi/Kconfig             | 15 +++++++++++++++
>>>>    drivers/acpi/processor_thermal.c | 19 ++++++++++++++++---
>>>>    2 files changed, 31 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
>>>> index 00dd309b6682..287cf58defbf 100644
>>>> --- a/drivers/acpi/Kconfig
>>>> +++ b/drivers/acpi/Kconfig
>>>> @@ -254,6 +254,21 @@ config ACPI_DOCK
>>>>    config ACPI_CPU_FREQ_PSS
>>>>           bool
>>>>
>>>> +config ACPI_CPU_FREQ_THERM_HAS_PARAMS
>>>> +       bool "CPU frequency throttling control"
>>>> +       depends on ACPI_PROCESSOR
>>>> +
>>>> +config ACPI_CPU_FREQ_THERM_MIN_THROT_PCTG
>>>> +       int "Minimum throttle percentage for processor_thermal cooling device"
>>>> +       depends on ACPI_CPU_FREQ_THERM_HAS_PARAMS
>>>> +       default 20
>>>> +       help
>>>> +         The processor_thermal driver uses this config to calculate the
>>>> +         percentage amount by which cpu frequency must be reduced for each
>>>> +         cooling state. The config is also used to calculate the maximum number
>>>> +         of throttling steps or cooling states supported by the driver. Value
>>>> +         must be an unsigned integer in the range [1, 50].
>>>> +
>>>
>>> I don't think that the new Kconfig symbols are particularly useful.
>>> At least they don't help the distro vendors that each would need to
>>> pick up a specific value for their kernel anyway.
>>>
>>> I also wonder how the users building their own kernels are supposed to
>>> determine the values suitable for the target systems.
>>>
>>
>> We observed some perf gain after reducing the throttle percentage.
>> Currently, kept the default to '20%' as before.
> 
> So you should add this information to the patch changelog, ideally
> along with the description of the hardware configuration in which the
> improvement has been observed.
> 

Sure, will add in v2.

>> Based on need, a vendor can overwrite the default value with macro
>> 'CONFIG_ACPI_CPU_FREQ_THERM_MIN_THROT_PCTG'. Otherwise, the behavior
>> will remain same.
> 
> Yes, that's how it works.
> 
> What I'm saying is that the way it works does not appear to be
> particularly useful.
> 
> For example, how exactly is a distribution supposed to guess the
> "right" value for their general-purpose kernel?

We tested on Tegra241 (Grace) SoC with "5%" throttle percentage.
Didn't change the default value as behavior could be different on other 
chips.
An alternate way could be to overwrite the default value for the 
specific SoC using "arm_smccc_get_soc_id_version()" check. But not sure 
if such change in the generic "processor_thermal" driver is Okay?
Please suggest if the above sounds fine or any better way?

Thank you,
Sumit Gupta