Re: [PATCH v4 6/6] cpufreq: CPPC: Support for autonomous selection in cppc_cpufreq

["zhenglifeng (A)" <zhenglifeng1@huawei.com>]

On 2025/1/16 19:39, Russell Haley wrote:

> Hello,
> 
> I noticed something here just as a user casually browsing the mailing list.
> 
> On 1/13/25 6:21 AM, Lifeng Zheng wrote:
>> Add sysfs interfaces for CPPC autonomous selection in the cppc_cpufreq
>> driver.
>>
>> Signed-off-by: Lifeng Zheng <zhenglifeng1@huawei.com>
>> ---
>>  .../ABI/testing/sysfs-devices-system-cpu      |  54 +++++++++
>>  drivers/cpufreq/cppc_cpufreq.c                | 109 ++++++++++++++++++
>>  2 files changed, 163 insertions(+)
>>
>> diff --git a/Documentation/ABI/testing/sysfs-devices-system-cpu b/Documentation/ABI/testing/sysfs-devices-system-cpu
>> index 206079d3bd5b..3d87c3bb3fe2 100644
>> --- a/Documentation/ABI/testing/sysfs-devices-system-cpu
>> +++ b/Documentation/ABI/testing/sysfs-devices-system-cpu
>> @@ -268,6 +268,60 @@ Description:	Discover CPUs in the same CPU frequency coordination domain
>>  		This file is only present if the acpi-cpufreq or the cppc-cpufreq
>>  		drivers are in use.
>>  
> 
> [...snip...]
> 
>> +What:		/sys/devices/system/cpu/cpuX/cpufreq/energy_perf
>> +Date:		October 2024
>> +Contact:	linux-pm@vger.kernel.org
>> +Description:	Energy performance preference
>> +
>> +		Read/write an 8-bit integer from/to this file. This file
>> +		represents a range of values from 0 (performance preference) to
>> +		0xFF (energy efficiency preference) that influences the rate of
>> +		performance increase/decrease and the result of the hardware's
>> +		energy efficiency and performance optimization policies.
>> +
>> +		Writing to this file only has meaning when Autonomous Selection is
>> +		enabled.
>> +
>> +		This file only presents if the cppc-cpufreq driver is in use.
> 
> In intel_pstate driver, there is file with near-identical semantics:
> 
> /sys/devices/system/cpu/cpuX/cpufreq/energy_performance_preference
> 
> It also accepts a few string arguments and converts them to integers.
> 
> Perhaps the same name should be used, and the semantics made exactly
> identical, and then it could be documented as present for either
> cppc_cpufreq OR intel_pstate?
> 
> I think would be more elegant if userspace tooling could Just Work with
> either driver.
> 
> One might object that the frequency selection behavior that results from
> any particular value of the register itself might be different, but they
> are *already* different between Intel's P and E-cores in the same CPU
> package. (Ugh.)

Yes, I should use the same name. Thanks.

As for accepting string arguments and converting them to integers, I don't
think it is necessary. It'll be a litte confused if someone writes a raw
value and reads a string I think. I prefer to let users freely set this
value.

In addition, there are many differences between the implementations of
energy_performance_preference in intel_pstate and cppc_cpufreq (and
amd-pstate...). It is really difficult to explain all this differences in
this document. So I'll leave it to be documented as present for
cppc_cpufreq only.

> 
> --
> Thanks,
> Russell
> 
> 
>