On 9/26/2024 08:58, Mark Pearson wrote:
Thanks Mario,
On Wed, Sep 25, 2024, at 10:59 PM, Mario Limonciello wrote:
From: Mario Limonciello <mario.limonciello@xxxxxxx>
There are two major ways to tune platform performance in Linux:
* ACPI platform profile
* Manually tuning APU performance
Changing the ACPI platform profile is a "one stop shop" to change
performance limits and fan curves all at the same time.
On AMD systems the manual tuning methods typically involve changing
values of settings such as fPPT, sPPT or SPL.
The problem with changing these settings manually is that the definition
of the ACPI platform profile if supported by the hardware is no longer
accurate. At best this can cause misrepresenting the state of the
platform to userspace and at worst can cause the state machine into an
invalid state.
The existence and continued development of projects such as ryzenadj which
manipulate debugging interfaces show there is a demand for manually tuning
performance.
Furthermore some systems (such as ASUS and Lenovo handhelds) offer an
ACPI-WMI interface for changing these settings. If using anything outside
that WMI interface the state will be wrong. If using that WMI interface
the platform profile will be wrong.
This series introduces a "custom" ACPI platform profile and adds support
for the AMD PMF driver to use it when a user has enabled manual
adjustments.
If agreeable a similar change should be made to asus-armoury and any other
drivers that export the ability to change these settings but also a
platform profile.
As someone who supports customers on Lenovo devices and hits the occasional situation where a user has made strange tweaks to different power related settings, and then complains about power or thermal issues - I love the idea that it can be made clear the system has been 'adjusted' in a non standard way. I can also see why users would want interfaces to do those changes.
JFYI we're going to do something really similar in amdgpu when people
have enabled overclocking. That's part of the inspiration for this RFC.
https://lore.kernel.org/amd-gfx/CADnq5_M+vxGV6y8oEQHC+-CcqV-vW9ND4SsRHqHKbwR_b0iJ9g@xxxxxxxxxxxxxx/T/#m1d69399c3e799ea1ef2014a27fd6e555f9e70ba0
Some suggestions:
I'm wondering if we can make it so a driver can register only a 'custom' profile as an extra profile handler?
The thinking here is the custom setting in this series is implemented for the amd sps driver, and therefore on a regular Lenovo laptop wouldn't be used, as the thinkpad_acpi driver will grab the profile slot, Users on Lenovo systems aren't going to be able to get at these extra tweaks (unless they unload thinkpad_acpi, which has other side effects).
Well the RFC was just to show it for the AMD PMF driver, but I think
that thinkpad_acpi, asus_armoury etc could all potentially implement the
'custom' bit too if they offer an ACPI-WMI interface to similar settings.
If the sps driver can offer a custom mode, separately from thinkpad_acpi, then users can tweak settings to their hearts content but get back to regular mode when done.
I also think there needs to be a way that when you switch from custom back to a 'regular' profile that it would do a clean up of anything tweaked. e.g. when switching away from custom the ppd driver should call a 'custom mode cleanup' function, so things can be undone and returned to how they were when it was started.
Mark
I guess what you're proposing is that multiple drivers register as
profile handlers and they might not all export the same features.
If we did something like this we could instead have the core call
callbacks for all platform profile handlers. We could also drop a pile
of quirks from amd-pmf where there are some ASUS systems that advertise
SPS in in the PMF framework and also asus-wmi provides it.
If I'm following you right, I generally like this idea.
