linux-kernel - Re: [PATCH v4 6/6] cpufreq: CPPC: Support for autonomous selection in cppc

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: <270a1cce-8afe-497a-b30b-56157d75a863@amd.com>
Date: Fri, 17 Jan 2025 08:30:45 -0600
From: Mario Limonciello <mario.limonciello@....com>
To: "zhenglifeng (A)" <zhenglifeng1@...wei.com>,
 Russell Haley <yumpusamongus@...il.com>, rafael@...nel.org, lenb@...nel.org,
 robert.moore@...el.com, viresh.kumar@...aro.org, gautham.shenoy@....com,
 ray.huang@....com, pierre.gondois@....com
Cc: acpica-devel@...ts.linux.dev, linux-acpi@...r.kernel.org,
 linux-kernel@...r.kernel.org, linux-pm@...r.kernel.org, linuxarm@...wei.com,
 jonathan.cameron@...wei.com, zhanjie9@...ilicon.com, lihuisong@...wei.com,
 hepeng68@...wei.com, fanghao11@...wei.com
Subject: Re: [PATCH v4 6/6] cpufreq: CPPC: Support for autonomous selection in
 cppc_cpufreq

On 1/16/2025 21:11, zhenglifeng (A) wrote:
> 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@...wei.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@...r.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.

At least the interface to userspace I think we should do the best we can 
to be the same between all the drivers if possible.

For example; I've got a patch that I may bring up in a future kernel 
cycle that adds raw integer writes to amd-pstates 
energy_performance_profile to behave the same way intel-pstate does.

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