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
