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

[Gautham R.Shenoy <gautham.shenoy@amd.com>]

Mario Limonciello <mario.limonciello@amd.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@amd.com>
>> Reviewed-by: Mario Limonciello <mario.limonciello@amd.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.