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 3:07 PM, Bastien Nocera wrote:
> On Thu, 2020-09-17 at 14:45 +0200, Hans de Goede wrote:
>> 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_p
>>>> rofile
>>>>
>>>> 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_perform
>>>> ance_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
> 
> The "description strings" need to come from a list. We're not going to
> use those anywhere but in debug messages, so we need a way to figure
> out what they would correspond to.

The whole idea behind the 101 possible profiles setup is to make the
API flexible/extensible. We don't know how much other profiles other
implementations will offer, nor what the naming used by that vendor
will be. So offering a fixed list in advance is sort of impossible.

For p-p-d the descriptions are probably not interesting at all,
but I think it would still be good for the driver to list the
Windows names of the various profiles in the mappings file.


> 
>> 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.
> 
> That sounds slightly more complicated than I'd have expected it to be,
> but I can work with that API.

Well Benjamin made a very valid point that we need to be able to
sort the various profiles along the low-power <-> performance axis
and maybe even also show some relative distance if some options
are closer together then others.  Which lead to (Bejamin's) 0-100
idea. I think this makes a lot of sense as it should give us
enough flexibility to cover other x86 vendor's implementations
and hopefully also similar functionality on other architectures.

I agree that this is slightly more complicated then I initially
expected too, but that is the price of building in some much
needed flexibility.  If you have options to simplify the interface
though I'm all ears.

Regards,

Hans