linux-kernel - Re: [RFC 2/2] platform/x86/amd: pmf: Add manual control support

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: 
 <CAGwozwGtqwOOfrUpjLghW4JCKqcFk9ut-X0MBvHAm37YVS51tw@mail.gmail.com>
Date: Thu, 26 Sep 2024 13:00:16 +0200
From: Antheas Kapenekakis <lkml@...heas.dev>
To: Shyam Sundar S K <Shyam-sundar.S-k@....com>
Cc: Mario Limonciello <superm1@...nel.org>,
 "Rafael J . Wysocki" <rafael@...nel.org>,
	Hans de Goede <hdegoede@...hat.com>,
 Ilpo Järvinen <ilpo.jarvinen@...ux.intel.com>,
	"Luke D . Jones" <luke@...nes.dev>, Mark Pearson <mpearson-lenovo@...ebb.ca>,
	"open list:AMD PMF DRIVER" <platform-driver-x86@...r.kernel.org>,
	open list <linux-kernel@...r.kernel.org>,
	"open list:ACPI" <linux-acpi@...r.kernel.org>,
 "Derek J . Clark" <derekjohn.clark@...il.com>,
	me@...egospodneti.ch, Denis Benato <benato.denis96@...il.com>,
	Mario Limonciello <mario.limonciello@....com>
Subject: Re: [RFC 2/2] platform/x86/amd: pmf: Add manual control support

Hi Shyam,

> I appreciate the proposal, but giving users this control seems similar
> to using tools like Ryzenadj or Ryzen Master, which are primarily for
> overclocking. Atleast Ryzen Master has a dedicated mailbox with PMFW.

In the laptop market I agree with you. However, in the handheld
market, users expect to be able to lower the power envelope of the
device on demand in a granular fashion. As the battery drop is
measured in Watts, tying a slider to Watts is a natural solution.

Most of the time, when those controls are used it is to limit the
thermal envelope of the device, not exceed it. We want to remove the
use of these tools and allow manufacturers the ability to customise
the power envelope they offer to users.

> While some existing PMF mailboxes are being deprecated, and SPL has
> been removed starting with Strix[1] due to the APTS method.
>
> It's important to use some settings together rather than individually
> (which the users might not be aware of). For instance, updating SPL
> requires corresponding updates to STT limits to avoid negative outcomes.

This suggestion was referring to a combined slider, much like the
suggestion below. So STT limits would be modified in tandem,
respecting manufacturer profiles. See comments below.

If you find the name SPL disagreeable, it could be named {tdp,
tdp_min, tdp_max}. This is the solution used by Valve on the Steam
Deck (power1_cap{+min,max}, power2_cap{+min,max}).

In addition, boost is seen as detrimental to handheld devices, with
most users disliking and disabling it. Steam Deck does not use boost.
It is disabled by Steam (power1_cap == power2_cap). So STT and STAPM
are not very relevant. In addition, Steam Deck van gogh has a more
linear response so TDP limits are less required.

> Additionally, altering these parameters can exceed thermal limits and
> potentially void warranties.
>
> Considering CnQF, why not let OEMs opt-in and allow the algorithm to
> manage power budgets, rather than providing these controls to users
> from the kernel when userspace tools already exist?
>
> Please note that on systems with Smart PC enabled, if users manually
> adjust the system thermals, it can lead to the thermal controls
> becoming unmanageable.
>
> Please consider this perspective.
>
> [1]
> https://github.com/torvalds/linux/blob/master/drivers/platform/x86/amd/pmf/sps.c#L193

This slider looks like it would do what we would need. I will note the
importance of tying the slider to Watts to manage user expectation and
adding more gradations (e.g., 15-25, every 1-2W for sub-50W devices).

We have found automatic solutions to not work in the handheld market,
as most AAA games will consume the maximum TDP the profile allows. In
addition, due to performance non-linearities above e.g., 15W,
performance will be similar. For example, on the Legion Go,
performance might increase 20% when going from 17W-25W, however
consumption will increase from ~30W to 45W (50%) which greatly affects
battery life.

Therefore, we need to allow the user to choose between 20% and extra
battery life. If you think we can use an algorithm for this I would
love to know.

Much like you, we dislike AutoTDP solutions that use e.g., RyzenAdj, as they:
 1) Do not respect manufacturer limits
 2) Cause system instability such as stutters when setting values
 3) Can cause crashes if they access the mailbox at the same time as
the AMD drm driver.

Thank you for your time,
Antheas