Re: RFC: offering a standardized (/sys/class) userspace API for selecting system/laptop performance-profiles

[Benjamin Berg <bberg@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3057 bytes --]

Hi,

On Thu, 2020-09-17 at 13:22 +0200, Hans de Goede wrote:
> The big question is what do we do if there are more then 3 profiles?

The Intel p-state driver has the 4 modes:
 * performance
 * balance_performance
 * balance_power
 * power

This seems to also match what windows does with their power slider,
there the modes are mapped to integer values:
 * power: 25
 * balance_power: 50
 * balance_performance: 75
 * performance: 100

Which appears to be the same as what newer DPTF versions use. For older
DPTF versions this is done through OEM variables, which also appear to
have 4 separate states usually. The MS power slider seems to define the
four possible modes:
 * Battery Saver
 * Better Battery
 * Better Performance
 * Best Performance

https://docs.microsoft.com/en-us/windows-hardware/customize/desktop/customize-power-slider#set-default-power-slider-mode

> One option would be something like the following:
> 
> cat /sys/class/system_performance_profile/thinkpad_acpi/performance_profile
> 
> low-power [balanced] performance

I guess userspace is responsible for setting all drivers to the correct
state when the user changes a global system setting?

> cat /sys/class/system_performance_profile/thinkpad_acpi/extra_performance_profiles
> 
> extra-low-power balanced-performance-mix
> 
> So we add an optional extra_performance_profiles sysfs attribute and we ask all
> drivers implemeting this class to implement at least the 3 standard profiles
> (by mapping 3 of their options to these) and optional they can offer extra
> profiles (with free form names) in the extra_performance_profiles
> sysfs attribute under the class-device.

I think it would be good if userspace can figure out where such these
extra profiles would be sorted in on the "power save -- performance"
scale. Assigning an integer in the range of 0-100 might be a solution
for that.

Benjamin

> The idea behind putting the extra profiles in a separate sysfs-attribute
> is that reading the main performance_profile attribute will always show
> one selected, even if one of the extra profiles is actually in use,
> then the driver should also show the closest standardized profile as
> being active.
> 
> This will allow userspace code to always rely on the standard interface
> both for getting a representation of the currently active profile as well
> as for setting the active profile.
> 
> Elia, Mark, I assume that both of you want to get your patches for this
> upstream sooner, rather then later. But I think we should put them on
> hold until we have an agreement on a shared userspace API for this.
> 
> I would like to think that the above proposal is a good start,
> if we can quickly (*) decide on an userspace API here
> 
> Regards,
> 
> Hans
> 
> p.s.
> 
> I guess we should also add an optional lap_mode sysfs attribute
> to the class-device, to have all the info for the Thinkpads in
> one place.
> 
> 
> *) but not too quickly, it is important we get this right
> 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 833 bytes --]