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] [thread-next>] [day] [month] [year] [list]
Message-ID: <19cbf20f-cf06-4776-8d14-973b090f7242@amd.com>
Date: Wed, 19 Jun 2024 14:45:57 -0500
From: Mario Limonciello <mario.limonciello@....com>
To: Perry Yuan <perry.yuan@....com>, rafael.j.wysocki@...el.com,
 viresh.kumar@...aro.org, gautham.shenoy@....com
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

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.

* 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.
   - 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?

> +
> +
>   Other performance and frequency values can be read back from
>   ``/sys/devices/system/cpu/cpuX/acpi_cppc/``, see :ref:`cppc_sysfs`.
>   


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ