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

[Hans de Goede <hdegoede@redhat.com>]

Hi,

On 9/17/20 2:22 PM, Benjamin Berg wrote:
> 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?

Yes.

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

Interesting, maybe the primary interface should even be an integer in
that range, so for each system_performance_profile class-device we
would then have the following attributes:

mappings (ro) - This attribute gives a list of valid performance-profile-values
              In the form of "<integer-value> <description-string>\n", e.g.:

              25 Low Power
              50 Balanced
              100 Performance

value (rw) - Integer in the range 0 (lowest performance setting) - 100
              (highest performance setting). Note most drivers will only
              support a number of specific discrete values, see the mappings
              attribute. Userspace may write an arbitrary value between 0
              and 100, this will be rounded to the closest supported discrete
              value.

value_string (ro) - String representation of the currently active value,
              this is a shortcut for looking up the string in the mappings
              attribute yourself.

lap_mode (ro) - <lap_mode text here>

Something like p-p-daemon would then just interact with the value and lap_mode
fields, ignoring the mappings. It would then also need to do some rounding of
its own when reading value to map things back to its own internal levels.
One issue for p-p-d here might be that it writes its internal integer value
corresponding to say "Low power", then reads back a value and when rounding
that to its own discrete steps ends up at a different level then "Low power".
This can be avoid by using the mappings file to get the supported discrete values
and then only generate mappings for the discrete values to its own internal
discrete steps once and always use those mappings, thus always writing a
supported discrete value, avoiding rounding issues.

I think that this will give us a nice and flexible interface. Note if
anyone disagrees, or has a better idea please speak up. Once we have
decided on what the interface is going to be, we are effectively stuck
with it.

Regards,

Hans








> 
> 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
>>