| Message ID | 20240926025955.1728766-1-superm1@kernel.org (mailing list archive) |
|---|---|
| Headers | show |
| Series | "custom" ACPI platform profile support | expand |
Hi Mario, Indeed, the proposal looks good but has a few rough edges that would make it unsuitable to use currently. Well, for the handheld use-case at least. This relates to issues of auto-discovery and how the kernel taint is applied. For the kernel taint, see my comments on patch 2. > 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. For laptops. A majority of users of handhelds find 3 settings too limiting. > On AMD systems the manual tuning methods typically involve changing > values of settings such as fPPT, sPPT or SPL. Those names are amd-pmf specific and this proposal does not allow for auto-discovery. Instead, expose attributes `custom_mode` and `custom_mode_choices`, that allow for querying the system for available custom modes and whether userspace can use them. In this case, the modes for amd-pmf could be `amd-pmf-spl` and `amd-pmf-user`. `amd-pmf-spl` could export the attrs {spl_min, spl_max, spl} and allow setting TDP using a slider a la Steam Deck. Here, manufacturers should be given complete control, e.g., with a LUT and the kernel should not taint. `amd-pmf-user` would expose what is shown in this proposal and taint the kernel. Unfortunately, without manufacturer intervention, this would be the default for the foreseeable future for boutique devices (e.g., GPD, OneXPlayer, Ayaneo). > 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. -demand- -> requirement. Over 90% of handheld users will end up using a slider. > 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. Indeed, it would be nice if such a change could be made for all manufacturer drivers. Much of this proposal would lower the need for something like asus-armoury, as asus-wmi would be fully capable of supporting this with few changes and around 70% of the asus-armoury attrs would then live under /sys/platform. This also gives us the opportunity for a much needed rename of the variables. I can speak with the out-of-tree Lenovo Legion Linux's maintainers and see if they would like to collaborate on this as well. Antheas
For testing purposes, the important part would be implementing dummy attrs for `custom_mode`, and `custom_mode_choices` that both return `amd-pmf-user` or a name you find more agreeable. Otherwise I cannot implement an autodiscovery process. If that change happens, we can begin testing as soon as the middle of next week. It does not matter if that name is not final, as it can be aliased in the future. Antheas
Thanks Mario, On Wed, Sep 25, 2024, at 10:59 PM, Mario Limonciello wrote: > From: Mario Limonciello <mario.limonciello@amd.com> > > 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. 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). 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
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@amd.com> >> >> 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@mail.gmail.com/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.
On Thu, Sep 26, 2024, at 2:14 PM, Mario Limonciello wrote: > 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@amd.com> >>> >>> 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@mail.gmail.com/T/#m1d69399c3e799ea1ef2014a27fd6e555f9e70ba0 > Nice :) >> >> 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. Yep - that was the idea. This feels like a step towards giving more control to power users - whilst keeping the basic simple for regular folk. I can imagine utilities that would use this to enable specific configurations, via the custom profile mode, for many different scenario's; whilst still allowing a user to get back to the tested and vendor approved setting if things go badly. Mark
> >> 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 think I considered that as part of my userspace software and reached the conclusion that if there is an EC, for most users it is best to program it and forgo the extra features. Otherwise they get weird bugs and conflicts, such as incorrect fan curves or their settings being reset randomly. On the Legion and Thinkpad series, the hardware binds would also cause this (Fn + BMH)/(Legion Go L + Y), and for Legion series specifically, the power button will have the wrong color. So I do not know if it is worth exploring as having it controllable from userspace in such a clean way. Of course, tinkerers could mess around by disabling modules to try something out and that would work fine, but I do not think it will be usable day to day. I personally gave up on the idea. However, having a load order and falling back to amd-pmf does have merit. E.g., the legion go will need a quirk for pmf too, and probably most laptop lines going forward. So that should be explored. > >> > >> 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. > > Yep - that was the idea. > > This feels like a step towards giving more control to power users - whilst keeping the basic simple for regular folk. > > I can imagine utilities that would use this to enable specific configurations, via the custom profile mode, for many different scenario's; whilst still allowing a user to get back to the tested and vendor approved setting if things go badly. I will note that for handhelds, having a TDP slider is basic functionality. So we need to find a way to give this control to users without tainting the kernel or requiring special workarounds in the case the manufacturer did not provide a WMI interface. This PR is a step in that direction, but then we need to deal with hardware limits and such to make sure it is safe. As far as fPPT and sPPt go, I will be honest and say I never had a user ask for them. However, unless the driver implements a LUT or some basic logic to enable/disable some sort of boost, they will need to be exposed to sysfs so userspace can do it. It does not mean that userspace will need to show that to users, just that it will do the interpolation to apply the correct boost if that is requested. Here I will note Legion Space did not do that on the Legion Go on WIndows for the first 5-6 months of its release. This lead to custom mode being completely broken from a user's perspective. Since the device is STT, if the user set the spl to 10W, well sPPT was 32W and fPPT was 43W so the device just kept boosting forever. However, one of the first BIOS versions added sPPT and fPPT to WMI, so we never had that problem in Linux. Now, Legion Space added sPPT and fPPT as sliders, which just causes annoyance for users, as they have to edit 3 sliders instead of one to get their desired performance level. To that end, both Asus and Lenovo offer sPPT and fPPT adjustment, so there is no risk with exposing that to userspace in Linux specifically. As long as the limits are bounded. Antheas
From: Mario Limonciello <mario.limonciello@amd.com> 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. Mario Limonciello (2): ACPI: Add support for a 'custom' profile platform/x86/amd: pmf: Add manual control support Documentation/ABI/testing/sysfs-amd-pmf | 10 +++ .../ABI/testing/sysfs-platform_profile | 1 + drivers/acpi/platform_profile.c | 1 + drivers/platform/x86/amd/pmf/Makefile | 1 + drivers/platform/x86/amd/pmf/core.c | 9 ++ drivers/platform/x86/amd/pmf/manual.c | 88 +++++++++++++++++++ drivers/platform/x86/amd/pmf/pmf.h | 5 ++ drivers/platform/x86/amd/pmf/sps.c | 4 + include/linux/platform_profile.h | 1 + 9 files changed, 120 insertions(+) create mode 100644 drivers/platform/x86/amd/pmf/manual.c