Hi,
On 10/5/20 12:29 AM, Elia Devito wrote:
Hi Hans,
On 2020-10-03 9:19 a.m., Hans de Goede wrote:
On modern systems CPU/GPU/... performance is often dynamically configurable
in the form of e.g. variable clock-speeds and TPD. The performance is often
automatically adjusted to the load by some automatic-mechanism (which may
very well live outside the kernel).
These auto performance-adjustment mechanisms often can be configured with
one of several performance-profiles, with either a bias towards low-power
consumption (and cool and quiet) or towards performance (and higher power
consumption and thermals).
Introduce a new performance_profile class/sysfs API which offers a generic
API for selecting the performance-profile of these automatic-mechanisms.
Cc: Mark Pearson <markpearson@xxxxxxxxxx>
Cc: Elia Devito <eliadevito@xxxxxxxxx>
Cc: Bastien Nocera <hadess@xxxxxxxxxx>
Cc: Benjamin Berg <bberg@xxxxxxxxxx>
Cc: linux-pm@xxxxxxxxxxxxxxx
Cc: linux-acpi@xxxxxxxxxxxxxxx
Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx>
---
.../testing/sysfs-class-performance_profile | 104 ++++++++++++++++++
1 file changed, 104 insertions(+)
create mode 100644
Documentation/ABI/testing/sysfs-class-performance_profile
diff --git a/Documentation/ABI/testing/sysfs-class-performance_profile
b/Documentation/ABI/testing/sysfs-class-performance_profile new file mode
100644
index 000000000000..9c67cae39600
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-class-performance_profile
@@ -0,0 +1,104 @@
+Performance-profile selection (e.g.
/sys/class/performance_profile/thinkpad_acpi/) +
+On modern systems CPU/GPU/... performance is often dynamically configurable
+in the form of e.g. variable clock-speeds and TPD. The performance is
often +automatically adjusted to the load by some automatic-mechanism
(which may +very well live outside the kernel).
+
+These auto performance-adjustment mechanisms often can be configured with
+one of several performance-profiles, with either a bias towards low-power
+consumption (and cool and quiet) or towards performance (and higher power
+consumption and thermals).
+
+The purpose of the performance_profile class is to offer a generic sysfs
+API for selecting the performance-profile of these automatic-mechanisms.
+
+Note that this API is only for selecting the performance-profile, it is
+NOT a goal of this API to allow monitoring the resulting performance
+characteristics. Monitoring performance is best done with device/vendor
+specific tools such as e.g. turbostat.
+
+Specifically when selecting a high-performance profile the actual achieved
+performance may be limited by various factors such as: the heat generated
by +other components, room temperature, free air flow at the bottom of a
laptop, +etc. It is explicitly NOT a goal of this API to let userspace know
about +any sub-optimal conditions which are impeding reaching the requested
+performance level.
+
+Since numbers are a rather meaningless way to describe performance-profiles
+this API uses strings to describe the various profiles. To make sure that
+userspace gets a consistent experience when using this API this API
document +defines a fixed set of profile-names. Drivers *must* map their
internal +profile representation/names onto this fixed set.
+
+If for some reason there is no good match when mapping then a new
profile-name +may be added. Drivers which wish to introduce new
profile-names must: +1. Have very good reasons to do so.
+2. Add the new profile-name to this document, so that future drivers which
also + have a similar problem can use the same new. Usually new
profile-names will + be added to the "extra profile-names" section of
this document. But in some + cases the set of standard profile-names may
be extended.
+
+What: /sys/class/performance_profile/<device>/
available_profiles
+Date: October 2020
+Contact: Hans de Goede <hdegoede@xxxxxxxxxx>
+Description:
+ Reading this file gives a space separated list of profiles
+ supported for this device.
+
+ Drivers must use the following standard profile-names
whenever
+ possible:
+
+ low-power: Emphasises low power consumption
+ (and also cool and
quiet)
+ balanced-low-power: Balances between low power
consumption
+ and performance with a
slight bias
+ towards low power
+ balanced: Balance between low power
consumption
+ and performance
+ balanced-performance: Balances between performance and
low
+ power consumption with
a slight bias
+ towards performance
+ performance: Emphasises performance
(and may lead to
+ higher temperatures and
fan speeds)
+
+ Userspace may expect drivers to offer at least several of
these
+ standard profile-names! If none of the above are a good
match
+ for some of the drivers profiles, then drivers may use
one of
+ these extra profile-names:
+ <reserved for future use>
+
+What: /sys/class/performance_profile/<device>/current_profile
+Date: October 2020
+Contact: Hans de Goede <hdegoede@xxxxxxxxxx>
+Description:
+ Reading this file gives the current selected profile for
this
+ device. Writing this file with one of the strings from
+ available_profiles changes the profile to the new value.
+
+ Reading this file may also return "custom". This is
intended for
+ drivers which have and export multiple knobs influencing
+ performance. Such drivers may very well still want to
offer a
+ set of profiles for easy of use and to be able to offer a
+ consistent standard API (this API) to userspace for
configuring
+ their performance. The "custom" value is intended for
when a
+ user has directly configured the knobs (through e.g. some
+ advanced control-panel for a GPU) and the knob values do
not
+ match any of the presets represented by the
+ performance-profiles. In this case writing this file will
+ override the modifications and restore the selected
presets.
+
+What: /sys/class/performance_profile/<device>/type
+Date: October 2020
+Contact: Hans de Goede <hdegoede@xxxxxxxxxx>
+Description:
+ Performance-profiles may be system-wide, or for a specific
+ device (e.g. CPU / GPU). System-wide profiles are
typically
+ used on devices where where a single cooling solution is
+ shared between all components, such as laptops and NUCs.
+
+ Reading this file indicates the type of the device for
which
+ the thermal-profile is being configured.
+
+ Valid values: "system"
+ Reserved for future use values: "cpu", "gpu"
--
2.28.0
This looks good to me, the only consideration I have is that in my opinion the
quiet profile and the cool profile should not necessarily match the low-power
state because the quiet profile could cause thermal throttling without
benefiting consumption, instead the cool profile (with the fans almost
always on) would lead to an unnecessary increase in noise.
Ah I see, so you are interpreting cool as "cool to touch / low temps" not
as in cool by not generating much heat. That is not an unreasonable interpretation
and I see that the hp-wmi stuff you are working on has separate cool and
quiet profiles (and does not seem to have one which explicit targets low-power).
So I agree that we should not lump these together leading to the following
set of standard profile names (for now, can be extended in the future) :
quiet: Emphasises quiet running
cool: Emphasises low temperatures
low-power: Emphasises low power consumption
balanced-low-power: Balances between low power consumption
and performance with a slight bias
towards low power
balanced: Balance between low power consumption
and performance
balanced-performance: Balances between performance and low
power consumption with a slight bias
towards performance
performance: Emphasises performance
another question is the notebooks that offer both quiet and cool profile,
which profile should be associated as low power?
That is a good question, IMHO the kernels role here is to provide a
mechanism to control these kinda profiles in various systems / components.
If the UI for this takes the form of a slider going from low-power
to performance, then on hardware which only offers cool and quiet
as options, like the hp-wmi interface seems to do, which one to
pick when the user selects low-power is a policy decision left
up to userspace. Likely the performance-profile-daemon Bastien is
working on, so from the sysfs API pov this is solved by just offering
cool and quiet as profile choices and then userspace needs to figure
out what to do (sorry Bastien).
Note if the driver knows that one of cool vs quiet also leads
to low-power, while for the other one that is not so much the case,
then it would make sense for the driver to also offer low-power as
an alias to one of the two (*) since the chances that the driver knows
this are better then that the performance-profile-daemon will know.
Regards,
Hans
*) or maybe in that case offer only low-power + one of the
other 2 options ? Either way works I guess...
