diff mbox series

[v5,1/3] Documentation: Add documentation for new platform_profile sysfs attribute

Message ID 20201202171120.65269-1-markpearson@lenovo.com (mailing list archive)
State Deferred, archived
Headers show
Series [v5,1/3] Documentation: Add documentation for new platform_profile sysfs attribute | expand

Commit Message

Mark Pearson Dec. 2, 2020, 5:11 p.m. UTC
On modern systems the platform performance, temperature, fan and other
hardware related characteristics are often dynamically configurable. The
profile is often automatically adjusted to the load by some
automatic-mechanism (which may very well live outside the kernel).

These auto platform-adjustment mechanisms often can be configured with
one of several 'platform-profiles', with either a bias towards low-power
consumption or towards performance (and higher power consumption and
thermals).

Introduce a new platform_profile sysfs API which offers a generic API for
selecting the performance-profile of these automatic-mechanisms.

Co-developed-by: Mark Pearson <markpearson@lenovo.com>
Signed-off-by: Mark Pearson <markpearson@lenovo.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
---
Changes in v2:
 - updated to rst format
Changes in v3, v4 & v5:
 - version bump along with rest of patch series

 .../ABI/testing/sysfs-platform_profile.rst    | 66 +++++++++++++++++++
 1 file changed, 66 insertions(+)
 create mode 100644 Documentation/ABI/testing/sysfs-platform_profile.rst

Comments

Hans de Goede Dec. 3, 2020, 9:44 a.m. UTC | #1
Hi,

On 12/2/20 6:11 PM, Mark Pearson wrote:
> On modern systems the platform performance, temperature, fan and other
> hardware related characteristics are often dynamically configurable. The
> profile is often automatically adjusted to the load by some
> automatic-mechanism (which may very well live outside the kernel).
> 
> These auto platform-adjustment mechanisms often can be configured with
> one of several 'platform-profiles', with either a bias towards low-power
> consumption or towards performance (and higher power consumption and
> thermals).
> 
> Introduce a new platform_profile sysfs API which offers a generic API for
> selecting the performance-profile of these automatic-mechanisms.
> 
> Co-developed-by: Mark Pearson <markpearson@lenovo.com>
> Signed-off-by: Mark Pearson <markpearson@lenovo.com>
> Signed-off-by: Hans de Goede <hdegoede@redhat.com>

Thank you, patches 1 and 2 look good to me now, you may add my:

Reviewed-by: Hans de Goede <hdegoede@redhat.com>

To patch 2 (since I'm co-author of patch 1 it would be a bit weird
to add it there too).

Rafael, it would be great if you pick up patches 1 and 2 for merging
into 5.11 (assuming that you agree that they are ready) then I will merge
patch 3 once 5.11-rc1 is out.

Regards,

Hans



> ---
> Changes in v2:
>  - updated to rst format
> Changes in v3, v4 & v5:
>  - version bump along with rest of patch series
> 
>  .../ABI/testing/sysfs-platform_profile.rst    | 66 +++++++++++++++++++
>  1 file changed, 66 insertions(+)
>  create mode 100644 Documentation/ABI/testing/sysfs-platform_profile.rst
> 
> diff --git a/Documentation/ABI/testing/sysfs-platform_profile.rst b/Documentation/ABI/testing/sysfs-platform_profile.rst
> new file mode 100644
> index 000000000000..5f7b2a94409b
> --- /dev/null
> +++ b/Documentation/ABI/testing/sysfs-platform_profile.rst
> @@ -0,0 +1,66 @@
> +=======================================================================
> + Platform Profile Selection (e.g. /sys/firmware/acpi/platform_profile)
> +=======================================================================
> +
> +
> +On modern systems the platform performance, temperature, fan and other
> +hardware related characteristics are often dynamically configurable. The
> +profile is often automatically adjusted to the load by some
> +automatic mechanism (which may very well live outside the kernel).
> +
> +These auto platform adjustment mechanisms often can be configured with
> +one of several platform profiles, with either a bias towards low power
> +operation or towards performance.
> +
> +The purpose of the platform_profile attribute is to offer a generic sysfs
> +API for selecting the platform profile of these automatic mechanisms.
> +
> +Note that this API is only for selecting the platform 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 on their own cannot represent the multiple variables that a
> +profile will adjust (power consumption, heat generation, etc) this API
> +uses strings to describe the various profiles. To make sure that userspace
> +gets a consistent experience this API document defines a fixed set of
> +profile names. Drivers *must* map their internal profile representation
> +onto this fixed set.
> +
> +
> +If 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. Explain why the existing profile names canot be used.
> + 2. Add the new profile name, along with a clear description of the
> +    expected behaviour, to the documentation.
> +
> +:What:        /sys/firmware/acpi/platform_profile_choices
> +:Date:        October 2020
> +:Contact:     Hans de Goede <hdegoede@redhat.com>
> +:Description: This file contains a space-separated list of profiles supported for this device.
> +
> +              Drivers must use the following standard profile-names::
> +
> +         		 low-power:     Low power consumption
> +         		 cool:          Cooler operation
> +		         quiet:         Quieter operation
> +		         balanced:      Balance between low power consumption and performance
> +		         performance:   High performance operation
> +
> +              Userspace may expect drivers to offer more than one of these
> +              standard profile names.
> +
> +:What:        /sys/firmware/acpi/platform_profile
> +:Date:        October 2020
> +:Contact:     Hans de Goede <hdegoede@redhat.com>
> +: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.
>
Rafael J. Wysocki Dec. 7, 2020, 7:29 p.m. UTC | #2
On Thu, Dec 3, 2020 at 10:46 AM Hans de Goede <hdegoede@redhat.com> wrote:
>
> Hi,
>
> On 12/2/20 6:11 PM, Mark Pearson wrote:
> > On modern systems the platform performance, temperature, fan and other
> > hardware related characteristics are often dynamically configurable. The
> > profile is often automatically adjusted to the load by some
> > automatic-mechanism (which may very well live outside the kernel).
> >
> > These auto platform-adjustment mechanisms often can be configured with
> > one of several 'platform-profiles', with either a bias towards low-power
> > consumption or towards performance (and higher power consumption and
> > thermals).
> >
> > Introduce a new platform_profile sysfs API which offers a generic API for
> > selecting the performance-profile of these automatic-mechanisms.
> >
> > Co-developed-by: Mark Pearson <markpearson@lenovo.com>
> > Signed-off-by: Mark Pearson <markpearson@lenovo.com>
> > Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>
> Thank you, patches 1 and 2 look good to me now, you may add my:
>
> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
>
> To patch 2 (since I'm co-author of patch 1 it would be a bit weird
> to add it there too).
>
> Rafael, it would be great if you pick up patches 1 and 2 for merging
> into 5.11 (assuming that you agree that they are ready) then I will merge
> patch 3 once 5.11-rc1 is out.

I've applied patch [1/2] (as 5.11-rc material) for now, but I still
needed to fix it up somewhat.  Please check the result in my
bleeding-edge branch.

I'll get to the other patch tomorrow.

Thanks!
Hans de Goede Dec. 8, 2020, 9:11 a.m. UTC | #3
Hi,

On 12/7/20 8:29 PM, Rafael J. Wysocki wrote:
> On Thu, Dec 3, 2020 at 10:46 AM Hans de Goede <hdegoede@redhat.com> wrote:
>>
>> Hi,
>>
>> On 12/2/20 6:11 PM, Mark Pearson wrote:
>>> On modern systems the platform performance, temperature, fan and other
>>> hardware related characteristics are often dynamically configurable. The
>>> profile is often automatically adjusted to the load by some
>>> automatic-mechanism (which may very well live outside the kernel).
>>>
>>> These auto platform-adjustment mechanisms often can be configured with
>>> one of several 'platform-profiles', with either a bias towards low-power
>>> consumption or towards performance (and higher power consumption and
>>> thermals).
>>>
>>> Introduce a new platform_profile sysfs API which offers a generic API for
>>> selecting the performance-profile of these automatic-mechanisms.
>>>
>>> Co-developed-by: Mark Pearson <markpearson@lenovo.com>
>>> Signed-off-by: Mark Pearson <markpearson@lenovo.com>
>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>
>> Thank you, patches 1 and 2 look good to me now, you may add my:
>>
>> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
>>
>> To patch 2 (since I'm co-author of patch 1 it would be a bit weird
>> to add it there too).
>>
>> Rafael, it would be great if you pick up patches 1 and 2 for merging
>> into 5.11 (assuming that you agree that they are ready) then I will merge
>> patch 3 once 5.11-rc1 is out.
> 
> I've applied patch [1/2] (as 5.11-rc material) for now, but I still
> needed to fix it up somewhat.  Please check the result in my
> bleeding-edge branch.

Thank you.

> I'll get to the other patch tomorrow.

The other patch likely conflicts with a bunch of other thinkpad_acpi
changes already in pdx86/for-next; and I still need to review v5 of
it, so please do not apply it.

I will pick it up after 5.11-rc1 and send it out as part of a
pull-req for rc2.

Regards,

Hans
Hans de Goede Dec. 8, 2020, 10:28 a.m. UTC | #4
Hi,

On 12/8/20 10:11 AM, Hans de Goede wrote:
> Hi,
> 
> On 12/7/20 8:29 PM, Rafael J. Wysocki wrote:
>> On Thu, Dec 3, 2020 at 10:46 AM Hans de Goede <hdegoede@redhat.com> wrote:
>>>
>>> Hi,
>>>
>>> On 12/2/20 6:11 PM, Mark Pearson wrote:
>>>> On modern systems the platform performance, temperature, fan and other
>>>> hardware related characteristics are often dynamically configurable. The
>>>> profile is often automatically adjusted to the load by some
>>>> automatic-mechanism (which may very well live outside the kernel).
>>>>
>>>> These auto platform-adjustment mechanisms often can be configured with
>>>> one of several 'platform-profiles', with either a bias towards low-power
>>>> consumption or towards performance (and higher power consumption and
>>>> thermals).
>>>>
>>>> Introduce a new platform_profile sysfs API which offers a generic API for
>>>> selecting the performance-profile of these automatic-mechanisms.
>>>>
>>>> Co-developed-by: Mark Pearson <markpearson@lenovo.com>
>>>> Signed-off-by: Mark Pearson <markpearson@lenovo.com>
>>>> Signed-off-by: Hans de Goede <hdegoede@redhat.com>
>>>
>>> Thank you, patches 1 and 2 look good to me now, you may add my:
>>>
>>> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
>>>
>>> To patch 2 (since I'm co-author of patch 1 it would be a bit weird
>>> to add it there too).
>>>
>>> Rafael, it would be great if you pick up patches 1 and 2 for merging
>>> into 5.11 (assuming that you agree that they are ready) then I will merge
>>> patch 3 once 5.11-rc1 is out.
>>
>> I've applied patch [1/2] (as 5.11-rc material) for now, but I still
>> needed to fix it up somewhat.  Please check the result in my
>> bleeding-edge branch.
> 
> Thank you.
> 
>> I'll get to the other patch tomorrow.
> 
> The other patch likely conflicts with a bunch of other thinkpad_acpi
> changes already in pdx86/for-next; and I still need to review v5 of
> it, so please do not apply it.
> 
> I will pick it up after 5.11-rc1 and send it out as part of a
> pull-req for rc2.

Sorry I misread what you wrote, when you said you "applied patch [1/2]",
I now see that you have only merged:

"[PATCH v5 1/3] Documentation: Add documentation for new platform_profile sysfs attribute"

And that the other patch which you intend to merge is not the
thinkpad_acpi patch but:

"[PATCH v5 2/3] ACPI: platform-profile: Add platform profile support"

So please ignore what I said before.

###

I checked out the fixed up version of:
"[PATCH v5 1/3] Documentation: Add documentation for new platform_profile sysfs attribute"

Which you merged and it looks good to me, thanks.

Regards,

Hans
diff mbox series

Patch

diff --git a/Documentation/ABI/testing/sysfs-platform_profile.rst b/Documentation/ABI/testing/sysfs-platform_profile.rst
new file mode 100644
index 000000000000..5f7b2a94409b
--- /dev/null
+++ b/Documentation/ABI/testing/sysfs-platform_profile.rst
@@ -0,0 +1,66 @@ 
+=======================================================================
+ Platform Profile Selection (e.g. /sys/firmware/acpi/platform_profile)
+=======================================================================
+
+
+On modern systems the platform performance, temperature, fan and other
+hardware related characteristics are often dynamically configurable. The
+profile is often automatically adjusted to the load by some
+automatic mechanism (which may very well live outside the kernel).
+
+These auto platform adjustment mechanisms often can be configured with
+one of several platform profiles, with either a bias towards low power
+operation or towards performance.
+
+The purpose of the platform_profile attribute is to offer a generic sysfs
+API for selecting the platform profile of these automatic mechanisms.
+
+Note that this API is only for selecting the platform 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 on their own cannot represent the multiple variables that a
+profile will adjust (power consumption, heat generation, etc) this API
+uses strings to describe the various profiles. To make sure that userspace
+gets a consistent experience this API document defines a fixed set of
+profile names. Drivers *must* map their internal profile representation
+onto this fixed set.
+
+
+If 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. Explain why the existing profile names canot be used.
+ 2. Add the new profile name, along with a clear description of the
+    expected behaviour, to the documentation.
+
+:What:        /sys/firmware/acpi/platform_profile_choices
+:Date:        October 2020
+:Contact:     Hans de Goede <hdegoede@redhat.com>
+:Description: This file contains a space-separated list of profiles supported for this device.
+
+              Drivers must use the following standard profile-names::
+
+         		 low-power:     Low power consumption
+         		 cool:          Cooler operation
+		         quiet:         Quieter operation
+		         balanced:      Balance between low power consumption and performance
+		         performance:   High performance operation
+
+              Userspace may expect drivers to offer more than one of these
+              standard profile names.
+
+:What:        /sys/firmware/acpi/platform_profile
+:Date:        October 2020
+:Contact:     Hans de Goede <hdegoede@redhat.com>
+: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.