linux-kernel - Re: [PATCH v12 9/9] Documentation: cpufreq: amd-pstate: update doc for Per CPU boost control method

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]

Date: Fri, 21 Jun 2024 12:12:56 +0530
From: Gautham R.Shenoy <gautham.shenoy@....com>
To: Mario Limonciello <mario.limonciello@....com>, Perry Yuan
	<perry.yuan@....com>, <rafael.j.wysocki@...el.com>, <viresh.kumar@...aro.org>
CC: <Xinmei.Huang@....com>, <Xiaojian.Du@....com>, <Li.Meng@....com>,
	<linux-pm@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v12 9/9] Documentation: cpufreq: amd-pstate: update doc
 for Per CPU boost control method

Mario Limonciello <mario.limonciello@....com> writes:

> On 6/19/2024 04:16, Perry Yuan wrote:
>> Updates the documentation in `amd-pstate.rst` to include information about the
>> per CPU boost control feature. Users can now enable or disable the Core Performance
>> Boost (CPB) feature on individual CPUs using the `boost` sysfs attribute.
>> 
>> Signed-off-by: Perry Yuan <perry.yuan@....com>
>> Reviewed-by: Mario Limonciello <mario.limonciello@....com>
>> ---
>>   Documentation/admin-guide/pm/amd-pstate.rst | 20 ++++++++++++++++++++
>>   1 file changed, 20 insertions(+)
>> 
>> diff --git a/Documentation/admin-guide/pm/amd-pstate.rst b/Documentation/admin-guide/pm/amd-pstate.rst
>> index bcc0d9404c18..98e43c53c387 100644
>> --- a/Documentation/admin-guide/pm/amd-pstate.rst
>> +++ b/Documentation/admin-guide/pm/amd-pstate.rst
>> @@ -281,6 +281,26 @@ integer values defined between 0 to 255 when EPP feature is enabled by platform
>>   firmware, if EPP feature is disabled, driver will ignore the written value
>>   This attribute is read-write.
>>   
>> +``boost``
>> +The `boost` sysfs attribute provides control over the CPU core
>> +performance boost, allowing users to manage the maximum frequency limitation
>> +of the CPU. This attribute can be used to enable or disable the boost feature
>> +on individual CPUs.
>> +
>> +When the boost feature is enabled, the CPU can dynamically increase its frequency
>> +beyond the base frequency, providing enhanced performance for demanding workloads.
>> +On the other hand, disabling the boost feature restricts the CPU to operate at the
>> +base frequency, which may be desirable in certain scenarios to prioritize power
>> +efficiency or manage temperature.
>> +
>> +To manipulate the `boost` attribute, users can write a value of `0` to disable the
>> +boost or `1` to enable it, for the respective CPU using the sysfs path
>> +`/sys/devices/system/cpu/cpuX/cpufreq/boost`, where `X` represents the CPU number.
>> +
>> +It is important to note that modifying the global variable
>> +`amd_pstate_global_params.cpb_boost` will override the individual CPU settings.
>
> The whole point of the global cpb_boost is an easy way for software to 
> turn on/off for the whole package.
>
> This makes me wonder if we want a "custom" string for the global param 
> if one of the CPUs has been individually modified separately from the 
> global flag.  Then software can very easily tell when it's been toggled 
> for a given CPU or via the global flag.

Yeah, this is one usecase which may justify the need for a separate
amd_pstate/cpb_boost interface. i.e., if there are users who do want to
reset the boost state on all the CPUs if individual CPUs have
independently toggled the boost states. 

>
> * Basically if userspace wrote to a single CPU store a bit in the global 
> structure to say cpb_custom = true if it's not already set.
> * If writing to cpb_boost from sysfs then "cpb_custom = false"
> * If reading cpb_boost from sysfs and "cpb_custom = true" then double 
> check all CPUs.

Actually, we can maintain a counter which is set to nr_online_cpus when
the global cpb_boost is enabled and set to 0 when global cpb_boost is
disabled. When each individual CPU disables cpb , we decrement the value
of the counter. We increment the counter value when some individual CPU
enables cpb.

So global counter returns "enabled" if counter == nr_policies, returns
"disabled" if counter == 0 and "custom" for all other values of the
counter.


>    - If they don't have the same value return "custom".
>    - If they all have the same values this means software has updated 
> them all, set "cpb_custom = false" and then return enabled/disabled.
>
> What do you think?

Could be done. But again, are there users who want to see the "custom"
value ?

--
Thanks and Regards
gautham.