Re: Fw: [External] Re: [RFC] Documentation: Add documentation for new performance_profile sysfs class (Also Re: [PATCH 0/4] powercap/dtpm: Add the DTPM framework)
Hi, On 10/19/20 8:49 PM, Mark Pearson wrote: > Hi > >> On 19/10/2020 14:43, Hans de Goede wrote: >> Hi, >> >> On 10/18/20 2:31 PM, Rafael J. Wysocki wrote: >>> On Sun, Oct 18, 2020 at 11:41 AM Hans de Goede wrote: Hi, On 10/16/20 4:51 PM, Rafael J. Wysocki wrote: > On Fri, Oct 16, 2020 at 1:11 PM Hans de Goede wrote: >> >> > one from both threads to the Cc> >> >> Hi, >> >> On 10/14/20 5:42 PM, Rafael J. Wysocki wrote: >>> On Wed, Oct 14, 2020 at 4:06 PM Hans de Goede >>> wrote: On 10/14/20 3:33 PM, Rafael J. Wysocki wrote: >> >> >> > First, a common place to register a DPTF system profile seems to be > needed and, as I said above, I wouldn't expect more than one such > thing to be present in the system at any given time, so it may be > registered along with the list of supported profiles and user space > will have to understand what they mean. Mostly Ack, I would still like to have an enum for DPTF system profiles in the kernel and have a single piece of code map that enum to profile names. This enum can then be extended as necessary, but I want to avoid having one driver use "Performance" and the other "performance" or one using "performance-balanced" and the other "balanced-performance", etc. With the goal being that new drivers use existing values from the enum as much as possible, but we extend it where necessary. >>> >>> IOW, just a table of known profile names with specific indices assigned >>> to them. >> >> Yes. >> >>> This sounds reasonable. >>> > Second, irrespective of the above, it may be useful to have a > consistent way to pass performance-vs-power preference information > from user space to different parts of the kernel so as to allow them > to adjust their operation and this could be done with a system-wide > power profile attribute IMO. I agree, which is why I tried to tackle both things in one go, but as you said doing both in 1 API is probably not the best idea. So I believe we should park this second issue for now and revisit it when we find a need for it. >>> >>> Agreed. >>> Do you have any specific userspace API in mind for the DPTF system profile selection? >>> >>> Not really. >> >> So before /sys/power/profile was mentioned, but that seems more like >> a thing which should have a set of fixed possible values, iow that is >> out of scope for this discussion. > > Yes. > >> Since we all seem to agree that this is something which we need >> specifically for DPTF profiles maybe just add: >> >> /sys/power/dptf_current_profile (rw) >> /sys/power/dptf_available_profiles (ro) >> >> (which will only be visible if a dptf-profile handler >> has been registered) ? >> >> Or more generic and thus better (in case other platforms >> later need something similar) I think, mirror the: >> >> /sys/bus/cpu/devices/cpu#/cpufreq/energy_performance_* bits >> for a system-wide energy-performance setting, so we get: >> >> /sys/power/energy_performance_preference >> /sys/power/energy_performance_available_preferences > > But this is not about energy vs performance only in general, is it? > >> (again only visible when applicable) ? >> >> I personally like the second option best. > > But I would put it under /sys/firmware/ instead of /sys/power/ and I > would call it something like platform_profile (and > platform_profile_choices or similar). Currently we only have dirs under /sys/firmware: [hans@x1 ~]$ ls /sys/firmware acpi dmi efi memmap But we do have /sys/firmware/apci/pm_profile: Documentation/ABI/stable/sysfs-acpi-pmprofile What: /sys/firmware/acpi/pm_profile Date: 03-Nov-2011 KernelVersion: v3.2 Contact: linux-a...@vger.kernel.org Description: The ACPI pm_profile sysfs interface exports the platform power management (and performance) requirement expectations as provided by BIOS. The integer value is directly passed as retrieved from the FADT ACPI table. Values: For possible values see ACPI specification: 5.2.9 Fixed ACPI Description Table (FADT) Field: Preferred_PM_Profile Currently these values are defined by spec: 0 Unspecified 1 Desktop 2 Mobile 3 Workstation 4 Enterprise Server ... Since
Re: [RFC] Documentation: Add documentation for new performance_profile sysfs class (Also Re: [PATCH 0/4] powercap/dtpm: Add the DTPM framework)
On Mon, Oct 19, 2020 at 8:43 PM Hans de Goede wrote: > > Hi, > > On 10/18/20 2:31 PM, Rafael J. Wysocki wrote: > > On Sun, Oct 18, 2020 at 11:41 AM Hans de Goede wrote: > >> > >> Hi, > >> > >> On 10/16/20 4:51 PM, Rafael J. Wysocki wrote: > >>> On Fri, Oct 16, 2020 at 1:11 PM Hans de Goede wrote: > > one from both threads to the Cc> > > Hi, > > On 10/14/20 5:42 PM, Rafael J. Wysocki wrote: > > On Wed, Oct 14, 2020 at 4:06 PM Hans de Goede > > wrote: > >> On 10/14/20 3:33 PM, Rafael J. Wysocki wrote: > > > > >>> First, a common place to register a DPTF system profile seems to be > >>> needed and, as I said above, I wouldn't expect more than one such > >>> thing to be present in the system at any given time, so it may be > >>> registered along with the list of supported profiles and user space > >>> will have to understand what they mean. > >> > >> Mostly Ack, I would still like to have an enum for DPTF system > >> profiles in the kernel and have a single piece of code map that > >> enum to profile names. This enum can then be extended as > >> necessary, but I want to avoid having one driver use > >> "Performance" and the other "performance" or one using > >> "performance-balanced" and the other "balanced-performance", etc. > >> > >> With the goal being that new drivers use existing values from > >> the enum as much as possible, but we extend it where necessary. > > > > IOW, just a table of known profile names with specific indices assigned > > to them. > > Yes. > > > This sounds reasonable. > > > >>> Second, irrespective of the above, it may be useful to have a > >>> consistent way to pass performance-vs-power preference information > >>> from user space to different parts of the kernel so as to allow them > >>> to adjust their operation and this could be done with a system-wide > >>> power profile attribute IMO. > >> > >> I agree, which is why I tried to tackle both things in one go, > >> but as you said doing both in 1 API is probably not the best idea. > >> So I believe we should park this second issue for now and revisit it > >> when we find a need for it. > > > > Agreed. > > > >> Do you have any specific userspace API in mind for the > >> DPTF system profile selection? > > > > Not really. > > So before /sys/power/profile was mentioned, but that seems more like > a thing which should have a set of fixed possible values, iow that is > out of scope for this discussion. > >>> > >>> Yes. > >>> > Since we all seem to agree that this is something which we need > specifically for DPTF profiles maybe just add: > > /sys/power/dptf_current_profile(rw) > /sys/power/dptf_available_profiles (ro) > > (which will only be visible if a dptf-profile handler > has been registered) ? > > Or more generic and thus better (in case other platforms > later need something similar) I think, mirror the: > > /sys/bus/cpu/devices/cpu#/cpufreq/energy_performance_* bits > for a system-wide energy-performance setting, so we get: > > /sys/power/energy_performance_preference > /sys/power/energy_performance_available_preferences > >>> > >>> But this is not about energy vs performance only in general, is it? > >>> > (again only visible when applicable) ? > > I personally like the second option best. > >>> > >>> But I would put it under /sys/firmware/ instead of /sys/power/ and I > >>> would call it something like platform_profile (and > >>> platform_profile_choices or similar). > >> > >> Currently we only have dirs under /sys/firmware: > >> > >> [hans@x1 ~]$ ls /sys/firmware > >> acpi dmi efi memmap > >> > >> But we do have /sys/firmware/apci/pm_profile: > >> > >> Documentation/ABI/stable/sysfs-acpi-pmprofile > >> > >> What: /sys/firmware/acpi/pm_profile > >> Date: 03-Nov-2011 > >> KernelVersion: v3.2 > >> Contact:linux-a...@vger.kernel.org > >> Description:The ACPI pm_profile sysfs interface exports the platform > >> power management (and performance) requirement expectations > >> as provided by BIOS. The integer value is directly passed > >> as > >> retrieved from the FADT ACPI table. > >> Values: For possible values see ACPI specification: > >> 5.2.9 Fixed ACPI Description Table (FADT) > >> Field: Preferred_PM_Profile > >> > >> Currently these values are defined by spec: > >> 0 Unspecified > >> 1 Desktop > >> 2 Mobile > >> 3 Workstation > >> 4 Enterprise Server > >> ... > >> > >> Since all platforms which we need this for are ACPI based > >> (and the
Re: Fw: [External] Re: [RFC] Documentation: Add documentation for new performance_profile sysfs class (Also Re: [PATCH 0/4] powercap/dtpm: Add the DTPM framework)
Hi > On 19/10/2020 14:43, Hans de Goede wrote: Hi, On 10/18/20 2:31 PM, Rafael J. Wysocki wrote: On Sun, Oct 18, 2020 at 11:41 AM Hans de Goede wrote: Hi, On 10/16/20 4:51 PM, Rafael J. Wysocki wrote: On Fri, Oct 16, 2020 at 1:11 PM Hans de Goede wrote: Hi, On 10/14/20 5:42 PM, Rafael J. Wysocki wrote: On Wed, Oct 14, 2020 at 4:06 PM Hans de Goede wrote: On 10/14/20 3:33 PM, Rafael J. Wysocki wrote: First, a common place to register a DPTF system profile seems to be needed and, as I said above, I wouldn't expect more than one such thing to be present in the system at any given time, so it may be registered along with the list of supported profiles and user space will have to understand what they mean. Mostly Ack, I would still like to have an enum for DPTF system profiles in the kernel and have a single piece of code map that enum to profile names. This enum can then be extended as necessary, but I want to avoid having one driver use "Performance" and the other "performance" or one using "performance-balanced" and the other "balanced-performance", etc. With the goal being that new drivers use existing values from the enum as much as possible, but we extend it where necessary. IOW, just a table of known profile names with specific indices assigned to them. Yes. This sounds reasonable. Second, irrespective of the above, it may be useful to have a consistent way to pass performance-vs-power preference information from user space to different parts of the kernel so as to allow them to adjust their operation and this could be done with a system-wide power profile attribute IMO. I agree, which is why I tried to tackle both things in one go, but as you said doing both in 1 API is probably not the best idea. So I believe we should park this second issue for now and revisit it when we find a need for it. Agreed. Do you have any specific userspace API in mind for the DPTF system profile selection? Not really. So before /sys/power/profile was mentioned, but that seems more like a thing which should have a set of fixed possible values, iow that is out of scope for this discussion. Yes. Since we all seem to agree that this is something which we need specifically for DPTF profiles maybe just add: /sys/power/dptf_current_profile (rw) /sys/power/dptf_available_profiles (ro) (which will only be visible if a dptf-profile handler has been registered) ? Or more generic and thus better (in case other platforms later need something similar) I think, mirror the: /sys/bus/cpu/devices/cpu#/cpufreq/energy_performance_* bits for a system-wide energy-performance setting, so we get: /sys/power/energy_performance_preference /sys/power/energy_performance_available_preferences But this is not about energy vs performance only in general, is it? (again only visible when applicable) ? I personally like the second option best. But I would put it under /sys/firmware/ instead of /sys/power/ and I would call it something like platform_profile (and platform_profile_choices or similar). Currently we only have dirs under /sys/firmware: [hans@x1 ~]$ ls /sys/firmware acpi dmi efi memmap But we do have /sys/firmware/apci/pm_profile: Documentation/ABI/stable/sysfs-acpi-pmprofile What: /sys/firmware/acpi/pm_profile Date: 03-Nov-2011 KernelVersion: v3.2 Contact: linux-a...@vger.kernel.org Description: The ACPI pm_profile sysfs interface exports the platform power management (and performance) requirement expectations as provided by BIOS. The integer value is directly passed as retrieved from the FADT ACPI table. Values: For possible values see ACPI specification: 5.2.9 Fixed ACPI Description Table (FADT) Field: Preferred_PM_Profile Currently these values are defined by spec: 0 Unspecified 1 Desktop 2 Mobile 3 Workstation 4 Enterprise Server ... Since all platforms which we need this for are ACPI based (and the involved interfaces are also all ACPI interfaces) how about: /sys/firmware/acpi/platform_profile /sys/firmware/acpi/platform_profile_choices ? I think this goes nice together with /sys/firmware/acpi/pm_profile although that is read-only and this is a read/write setting. Rafel, would: /sys/firmware/acpi/platform_profile /sys/firmware/acpi/platform_profile_choices work for you ? Yes, it would. Great. So I think hat means that we have the most important part for moving forward with this. So I guess the plan for this now looks something like this. 1. Rewrite my API docs RFC to update it for the new /sys/firmware/acpi/platform_profile[_choices] plan (should be easy and a bunch of stuff like the "type" bit can just be dropped) 2. Add code somewhere under drivers/acpi which allows code from else where to register
Re: [RFC] Documentation: Add documentation for new performance_profile sysfs class (Also Re: [PATCH 0/4] powercap/dtpm: Add the DTPM framework)
Hi, On 10/18/20 2:31 PM, Rafael J. Wysocki wrote: > On Sun, Oct 18, 2020 at 11:41 AM Hans de Goede wrote: >> >> Hi, >> >> On 10/16/20 4:51 PM, Rafael J. Wysocki wrote: >>> On Fri, Oct 16, 2020 at 1:11 PM Hans de Goede wrote: >>> one from both threads to the Cc> Hi, On 10/14/20 5:42 PM, Rafael J. Wysocki wrote: > On Wed, Oct 14, 2020 at 4:06 PM Hans de Goede wrote: >> On 10/14/20 3:33 PM, Rafael J. Wysocki wrote: >>> First, a common place to register a DPTF system profile seems to be >>> needed and, as I said above, I wouldn't expect more than one such >>> thing to be present in the system at any given time, so it may be >>> registered along with the list of supported profiles and user space >>> will have to understand what they mean. >> >> Mostly Ack, I would still like to have an enum for DPTF system >> profiles in the kernel and have a single piece of code map that >> enum to profile names. This enum can then be extended as >> necessary, but I want to avoid having one driver use >> "Performance" and the other "performance" or one using >> "performance-balanced" and the other "balanced-performance", etc. >> >> With the goal being that new drivers use existing values from >> the enum as much as possible, but we extend it where necessary. > > IOW, just a table of known profile names with specific indices assigned > to them. Yes. > This sounds reasonable. > >>> Second, irrespective of the above, it may be useful to have a >>> consistent way to pass performance-vs-power preference information >>> from user space to different parts of the kernel so as to allow them >>> to adjust their operation and this could be done with a system-wide >>> power profile attribute IMO. >> >> I agree, which is why I tried to tackle both things in one go, >> but as you said doing both in 1 API is probably not the best idea. >> So I believe we should park this second issue for now and revisit it >> when we find a need for it. > > Agreed. > >> Do you have any specific userspace API in mind for the >> DPTF system profile selection? > > Not really. So before /sys/power/profile was mentioned, but that seems more like a thing which should have a set of fixed possible values, iow that is out of scope for this discussion. >>> >>> Yes. >>> Since we all seem to agree that this is something which we need specifically for DPTF profiles maybe just add: /sys/power/dptf_current_profile(rw) /sys/power/dptf_available_profiles (ro) (which will only be visible if a dptf-profile handler has been registered) ? Or more generic and thus better (in case other platforms later need something similar) I think, mirror the: /sys/bus/cpu/devices/cpu#/cpufreq/energy_performance_* bits for a system-wide energy-performance setting, so we get: /sys/power/energy_performance_preference /sys/power/energy_performance_available_preferences >>> >>> But this is not about energy vs performance only in general, is it? >>> (again only visible when applicable) ? I personally like the second option best. >>> >>> But I would put it under /sys/firmware/ instead of /sys/power/ and I >>> would call it something like platform_profile (and >>> platform_profile_choices or similar). >> >> Currently we only have dirs under /sys/firmware: >> >> [hans@x1 ~]$ ls /sys/firmware >> acpi dmi efi memmap >> >> But we do have /sys/firmware/apci/pm_profile: >> >> Documentation/ABI/stable/sysfs-acpi-pmprofile >> >> What: /sys/firmware/acpi/pm_profile >> Date: 03-Nov-2011 >> KernelVersion: v3.2 >> Contact:linux-a...@vger.kernel.org >> Description:The ACPI pm_profile sysfs interface exports the platform >> power management (and performance) requirement expectations >> as provided by BIOS. The integer value is directly passed as >> retrieved from the FADT ACPI table. >> Values: For possible values see ACPI specification: >> 5.2.9 Fixed ACPI Description Table (FADT) >> Field: Preferred_PM_Profile >> >> Currently these values are defined by spec: >> 0 Unspecified >> 1 Desktop >> 2 Mobile >> 3 Workstation >> 4 Enterprise Server >> ... >> >> Since all platforms which we need this for are ACPI based >> (and the involved interfaces are also all ACPI interfaces) >> how about: >> >> /sys/firmware/acpi/platform_profile >> /sys/firmware/acpi/platform_profile_choices >> >> ? >> >> I think this goes nice together with /sys/firmware/acpi/pm_profile >> although that is read-only and this is a read/write setting. >> >> Rafel, would: >> >>
Re: [RFC] Documentation: Add documentation for new performance_profile sysfs class (Also Re: [PATCH 0/4] powercap/dtpm: Add the DTPM framework)
On Sun, Oct 18, 2020 at 11:41 AM Hans de Goede wrote: > > Hi, > > On 10/16/20 4:51 PM, Rafael J. Wysocki wrote: > > On Fri, Oct 16, 2020 at 1:11 PM Hans de Goede wrote: > >> > >> >> one from both threads to the Cc> > >> > >> Hi, > >> > >> On 10/14/20 5:42 PM, Rafael J. Wysocki wrote: > >>> On Wed, Oct 14, 2020 at 4:06 PM Hans de Goede wrote: > On 10/14/20 3:33 PM, Rafael J. Wysocki wrote: > >> > >> > >> > > First, a common place to register a DPTF system profile seems to be > > needed and, as I said above, I wouldn't expect more than one such > > thing to be present in the system at any given time, so it may be > > registered along with the list of supported profiles and user space > > will have to understand what they mean. > > Mostly Ack, I would still like to have an enum for DPTF system > profiles in the kernel and have a single piece of code map that > enum to profile names. This enum can then be extended as > necessary, but I want to avoid having one driver use > "Performance" and the other "performance" or one using > "performance-balanced" and the other "balanced-performance", etc. > > With the goal being that new drivers use existing values from > the enum as much as possible, but we extend it where necessary. > >>> > >>> IOW, just a table of known profile names with specific indices assigned > >>> to them. > >> > >> Yes. > >> > >>> This sounds reasonable. > >>> > > Second, irrespective of the above, it may be useful to have a > > consistent way to pass performance-vs-power preference information > > from user space to different parts of the kernel so as to allow them > > to adjust their operation and this could be done with a system-wide > > power profile attribute IMO. > > I agree, which is why I tried to tackle both things in one go, > but as you said doing both in 1 API is probably not the best idea. > So I believe we should park this second issue for now and revisit it > when we find a need for it. > >>> > >>> Agreed. > >>> > Do you have any specific userspace API in mind for the > DPTF system profile selection? > >>> > >>> Not really. > >> > >> So before /sys/power/profile was mentioned, but that seems more like > >> a thing which should have a set of fixed possible values, iow that is > >> out of scope for this discussion. > > > > Yes. > > > >> Since we all seem to agree that this is something which we need > >> specifically for DPTF profiles maybe just add: > >> > >> /sys/power/dptf_current_profile(rw) > >> /sys/power/dptf_available_profiles (ro) > >> > >> (which will only be visible if a dptf-profile handler > >> has been registered) ? > >> > >> Or more generic and thus better (in case other platforms > >> later need something similar) I think, mirror the: > >> > >> /sys/bus/cpu/devices/cpu#/cpufreq/energy_performance_* bits > >> for a system-wide energy-performance setting, so we get: > >> > >> /sys/power/energy_performance_preference > >> /sys/power/energy_performance_available_preferences > > > > But this is not about energy vs performance only in general, is it? > > > >> (again only visible when applicable) ? > >> > >> I personally like the second option best. > > > > But I would put it under /sys/firmware/ instead of /sys/power/ and I > > would call it something like platform_profile (and > > platform_profile_choices or similar). > > Currently we only have dirs under /sys/firmware: > > [hans@x1 ~]$ ls /sys/firmware > acpi dmi efi memmap > > But we do have /sys/firmware/apci/pm_profile: > > Documentation/ABI/stable/sysfs-acpi-pmprofile > > What: /sys/firmware/acpi/pm_profile > Date: 03-Nov-2011 > KernelVersion: v3.2 > Contact:linux-a...@vger.kernel.org > Description:The ACPI pm_profile sysfs interface exports the platform > power management (and performance) requirement expectations > as provided by BIOS. The integer value is directly passed as > retrieved from the FADT ACPI table. > Values: For possible values see ACPI specification: > 5.2.9 Fixed ACPI Description Table (FADT) > Field: Preferred_PM_Profile > > Currently these values are defined by spec: > 0 Unspecified > 1 Desktop > 2 Mobile > 3 Workstation > 4 Enterprise Server > ... > > Since all platforms which we need this for are ACPI based > (and the involved interfaces are also all ACPI interfaces) > how about: > > /sys/firmware/acpi/platform_profile > /sys/firmware/acpi/platform_profile_choices > > ? > > I think this goes nice together with /sys/firmware/acpi/pm_profile > although that is read-only and this is a read/write setting. > > Rafel, would: > > /sys/firmware/acpi/platform_profile > /sys/firmware/acpi/platform_profile_choices > > work for you ?
Re: [RFC] Documentation: Add documentation for new performance_profile sysfs class (Also Re: [PATCH 0/4] powercap/dtpm: Add the DTPM framework)
Hi, On 10/16/20 4:51 PM, Rafael J. Wysocki wrote: > On Fri, Oct 16, 2020 at 1:11 PM Hans de Goede wrote: >> >> > from both threads to the Cc> >> >> Hi, >> >> On 10/14/20 5:42 PM, Rafael J. Wysocki wrote: >>> On Wed, Oct 14, 2020 at 4:06 PM Hans de Goede wrote: On 10/14/20 3:33 PM, Rafael J. Wysocki wrote: >> >> >> > First, a common place to register a DPTF system profile seems to be > needed and, as I said above, I wouldn't expect more than one such > thing to be present in the system at any given time, so it may be > registered along with the list of supported profiles and user space > will have to understand what they mean. Mostly Ack, I would still like to have an enum for DPTF system profiles in the kernel and have a single piece of code map that enum to profile names. This enum can then be extended as necessary, but I want to avoid having one driver use "Performance" and the other "performance" or one using "performance-balanced" and the other "balanced-performance", etc. With the goal being that new drivers use existing values from the enum as much as possible, but we extend it where necessary. >>> >>> IOW, just a table of known profile names with specific indices assigned to >>> them. >> >> Yes. >> >>> This sounds reasonable. >>> > Second, irrespective of the above, it may be useful to have a > consistent way to pass performance-vs-power preference information > from user space to different parts of the kernel so as to allow them > to adjust their operation and this could be done with a system-wide > power profile attribute IMO. I agree, which is why I tried to tackle both things in one go, but as you said doing both in 1 API is probably not the best idea. So I believe we should park this second issue for now and revisit it when we find a need for it. >>> >>> Agreed. >>> Do you have any specific userspace API in mind for the DPTF system profile selection? >>> >>> Not really. >> >> So before /sys/power/profile was mentioned, but that seems more like >> a thing which should have a set of fixed possible values, iow that is >> out of scope for this discussion. > > Yes. > >> Since we all seem to agree that this is something which we need >> specifically for DPTF profiles maybe just add: >> >> /sys/power/dptf_current_profile(rw) >> /sys/power/dptf_available_profiles (ro) >> >> (which will only be visible if a dptf-profile handler >> has been registered) ? >> >> Or more generic and thus better (in case other platforms >> later need something similar) I think, mirror the: >> >> /sys/bus/cpu/devices/cpu#/cpufreq/energy_performance_* bits >> for a system-wide energy-performance setting, so we get: >> >> /sys/power/energy_performance_preference >> /sys/power/energy_performance_available_preferences > > But this is not about energy vs performance only in general, is it? > >> (again only visible when applicable) ? >> >> I personally like the second option best. > > But I would put it under /sys/firmware/ instead of /sys/power/ and I > would call it something like platform_profile (and > platform_profile_choices or similar). Currently we only have dirs under /sys/firmware: [hans@x1 ~]$ ls /sys/firmware acpi dmi efi memmap But we do have /sys/firmware/apci/pm_profile: Documentation/ABI/stable/sysfs-acpi-pmprofile What: /sys/firmware/acpi/pm_profile Date: 03-Nov-2011 KernelVersion: v3.2 Contact:linux-a...@vger.kernel.org Description:The ACPI pm_profile sysfs interface exports the platform power management (and performance) requirement expectations as provided by BIOS. The integer value is directly passed as retrieved from the FADT ACPI table. Values: For possible values see ACPI specification: 5.2.9 Fixed ACPI Description Table (FADT) Field: Preferred_PM_Profile Currently these values are defined by spec: 0 Unspecified 1 Desktop 2 Mobile 3 Workstation 4 Enterprise Server ... Since all platforms which we need this for are ACPI based (and the involved interfaces are also all ACPI interfaces) how about: /sys/firmware/acpi/platform_profile /sys/firmware/acpi/platform_profile_choices ? I think this goes nice together with /sys/firmware/acpi/pm_profile although that is read-only and this is a read/write setting. Rafel, would: /sys/firmware/acpi/platform_profile /sys/firmware/acpi/platform_profile_choices work for you ? Regards, Hans
Re: Fw: [External] Re: [RFC] Documentation: Add documentation for new performance_profile sysfs class (Also Re: [PATCH 0/4] powercap/dtpm: Add the DTPM framework)
Hi, In data venerdì 16 ottobre 2020 16:43:09 CEST, Mark Pearson ha scritto: > based address> > > On 2020-10-16 10:32 a.m., Mark Pearson wrote: > > > > *From:* Elia Devito > > *Sent:* October 16, 2020 10:26 > > *To:* Rafael J. Wysocki ; Hans de Goede > > > > *Cc:* Daniel Lezcano ; Srinivas Pandruvada > > ; Lukasz Luba > > ; Linux Kernel Mailing List > > ; Linux PM ; > > Zhang, Rui ; Bastien Nocera ; > > Mark Pearson ; Limonciello, Mario > > ; Darren Hart ; Andy > > Shevchenko ; Mark Gross ; > > Benjamin Berg ; linux-a...@vger.kernel.org > > ; platform-driver-...@vger.kernel.org > > > > *Subject:* [External] Re: [RFC] Documentation: Add documentation for new > > performance_profile sysfs class (Also Re: [PATCH 0/4] powercap/dtpm: Add > > the DTPM framework) > > Hi, > > > > In data venerdì 16 ottobre 2020 13:10:54 CEST, Hans de Goede ha scritto: > >> >> one from both threads to the Cc> > >> > >> Hi, > >> > >> On 10/14/20 5:42 PM, Rafael J. Wysocki wrote: > >> > On Wed, Oct 14, 2020 at 4:06 PM Hans de Goede wrote: > >> >> On 10/14/20 3:33 PM, Rafael J. Wysocki wrote: > >> > >> > >> >>> First, a common place to register a DPTF system profile seems to be > >> >>> needed and, as I said above, I wouldn't expect more than one such > >> >>> thing to be present in the system at any given time, so it may be > >> >>> registered along with the list of supported profiles and user space > >> >>> will have to understand what they mean. > >> >> > >> >> Mostly Ack, I would still like to have an enum for DPTF system > >> >> profiles in the kernel and have a single piece of code map that > >> >> enum to profile names. This enum can then be extended as > >> >> necessary, but I want to avoid having one driver use > >> >> "Performance" and the other "performance" or one using > >> >> "performance-balanced" and the other "balanced-performance", etc. > >> >> > >> >> With the goal being that new drivers use existing values from > >> >> the enum as much as possible, but we extend it where necessary. > >> > > >> > IOW, just a table of known profile names with specific indices assigned > >> > to > >> > them. > >> > >> Yes. > >> > >> > This sounds reasonable. > >> > > >> >>> Second, irrespective of the above, it may be useful to have a > >> >>> consistent way to pass performance-vs-power preference information > >> >>> from user space to different parts of the kernel so as to allow them > >> >>> to adjust their operation and this could be done with a system-wide > >> >>> power profile attribute IMO. > >> >> > >> >> I agree, which is why I tried to tackle both things in one go, > >> >> but as you said doing both in 1 API is probably not the best idea. > >> >> So I believe we should park this second issue for now and revisit it > >> >> when we find a need for it. > >> > > >> > Agreed. > >> > > >> >> Do you have any specific userspace API in mind for the > >> >> DPTF system profile selection? > >> > > >> > Not really. > >> > >> So before /sys/power/profile was mentioned, but that seems more like > >> a thing which should have a set of fixed possible values, iow that is > >> out of scope for this discussion. > >> > >> Since we all seem to agree that this is something which we need > >> specifically for DPTF profiles maybe just add: > >> > >> /sys/power/dptf_current_profile(rw) > >> /sys/power/dptf_available_profiles (ro) > >> > >> (which will only be visible if a dptf-profile handler > >> > >> has been registered) ? > >> > >> Or more generic and thus better (in case other platforms > >> later need something similar) I think, mirror the: > >> > >> /sys/bus/cpu/devices/cpu#/cpufreq/energy_performance_* bits > >> for a system-wide energy-performance setting, so we get: > >> > >> /sys/power/energy_performance_preference > >> /sys/power/energy_performance_available_preferences > >> > >> (again only visible when applicable) ? > >> > >> I personally like the second option best. > >> > >> Regards, > >> > >> Hans > > > > between the two, the second seems to me more appropriate. > > Considering that the various profiles interact with thermal behaviors > > what do > > you think of something like: > > > > /sys/power/thermal_profile_available_profiles > > /sys/power/thermal_profile_profile > > > > Regards, > > Elia > > I'm good with either but I do find 'profile_profile' slightly awkward to > say out loud (even though it's logically correct :)) > > How about just: > /sys/power/platform_profile > /sys/power/platform_profile_available > > As it covers the platform as a whole - fans, temperature, power, and > anything else that ends up getting thrown in? > > Mark Completely agree, I made a typo xD Elia
Re: [RFC] Documentation: Add documentation for new performance_profile sysfs class (Also Re: [PATCH 0/4] powercap/dtpm: Add the DTPM framework)
On Fri, Oct 16, 2020 at 1:11 PM Hans de Goede wrote: > > from both threads to the Cc> > > Hi, > > On 10/14/20 5:42 PM, Rafael J. Wysocki wrote: > > On Wed, Oct 14, 2020 at 4:06 PM Hans de Goede wrote: > >> On 10/14/20 3:33 PM, Rafael J. Wysocki wrote: > > > > >>> First, a common place to register a DPTF system profile seems to be > >>> needed and, as I said above, I wouldn't expect more than one such > >>> thing to be present in the system at any given time, so it may be > >>> registered along with the list of supported profiles and user space > >>> will have to understand what they mean. > >> > >> Mostly Ack, I would still like to have an enum for DPTF system > >> profiles in the kernel and have a single piece of code map that > >> enum to profile names. This enum can then be extended as > >> necessary, but I want to avoid having one driver use > >> "Performance" and the other "performance" or one using > >> "performance-balanced" and the other "balanced-performance", etc. > >> > >> With the goal being that new drivers use existing values from > >> the enum as much as possible, but we extend it where necessary. > > > > IOW, just a table of known profile names with specific indices assigned to > > them. > > Yes. > > > This sounds reasonable. > > > >>> Second, irrespective of the above, it may be useful to have a > >>> consistent way to pass performance-vs-power preference information > >>> from user space to different parts of the kernel so as to allow them > >>> to adjust their operation and this could be done with a system-wide > >>> power profile attribute IMO. > >> > >> I agree, which is why I tried to tackle both things in one go, > >> but as you said doing both in 1 API is probably not the best idea. > >> So I believe we should park this second issue for now and revisit it > >> when we find a need for it. > > > > Agreed. > > > >> Do you have any specific userspace API in mind for the > >> DPTF system profile selection? > > > > Not really. > > So before /sys/power/profile was mentioned, but that seems more like > a thing which should have a set of fixed possible values, iow that is > out of scope for this discussion. Yes. > Since we all seem to agree that this is something which we need > specifically for DPTF profiles maybe just add: > > /sys/power/dptf_current_profile(rw) > /sys/power/dptf_available_profiles (ro) > > (which will only be visible if a dptf-profile handler > has been registered) ? > > Or more generic and thus better (in case other platforms > later need something similar) I think, mirror the: > > /sys/bus/cpu/devices/cpu#/cpufreq/energy_performance_* bits > for a system-wide energy-performance setting, so we get: > > /sys/power/energy_performance_preference > /sys/power/energy_performance_available_preferences But this is not about energy vs performance only in general, is it? > (again only visible when applicable) ? > > I personally like the second option best. But I would put it under /sys/firmware/ instead of /sys/power/ and I would call it something like platform_profile (and platform_profile_choices or similar). Cheers!
Re: Fw: [External] Re: [RFC] Documentation: Add documentation for new performance_profile sysfs class (Also Re: [PATCH 0/4] powercap/dtpm: Add the DTPM framework)
based address> On 2020-10-16 10:32 a.m., Mark Pearson wrote: *From:* Elia Devito *Sent:* October 16, 2020 10:26 *To:* Rafael J. Wysocki ; Hans de Goede *Cc:* Daniel Lezcano ; Srinivas Pandruvada ; Lukasz Luba ; Linux Kernel Mailing List ; Linux PM ; Zhang, Rui ; Bastien Nocera ; Mark Pearson ; Limonciello, Mario ; Darren Hart ; Andy Shevchenko ; Mark Gross ; Benjamin Berg ; linux-a...@vger.kernel.org ; platform-driver-...@vger.kernel.org *Subject:* [External] Re: [RFC] Documentation: Add documentation for new performance_profile sysfs class (Also Re: [PATCH 0/4] powercap/dtpm: Add the DTPM framework) Hi, In data venerdì 16 ottobre 2020 13:10:54 CEST, Hans de Goede ha scritto: Hi, On 10/14/20 5:42 PM, Rafael J. Wysocki wrote: > On Wed, Oct 14, 2020 at 4:06 PM Hans de Goede wrote: >> On 10/14/20 3:33 PM, Rafael J. Wysocki wrote: >>> First, a common place to register a DPTF system profile seems to be >>> needed and, as I said above, I wouldn't expect more than one such >>> thing to be present in the system at any given time, so it may be >>> registered along with the list of supported profiles and user space >>> will have to understand what they mean. >> >> Mostly Ack, I would still like to have an enum for DPTF system >> profiles in the kernel and have a single piece of code map that >> enum to profile names. This enum can then be extended as >> necessary, but I want to avoid having one driver use >> "Performance" and the other "performance" or one using >> "performance-balanced" and the other "balanced-performance", etc. >> >> With the goal being that new drivers use existing values from >> the enum as much as possible, but we extend it where necessary. > > IOW, just a table of known profile names with specific indices assigned to > them. Yes. > This sounds reasonable. > >>> Second, irrespective of the above, it may be useful to have a >>> consistent way to pass performance-vs-power preference information >>> from user space to different parts of the kernel so as to allow them >>> to adjust their operation and this could be done with a system-wide >>> power profile attribute IMO. >> >> I agree, which is why I tried to tackle both things in one go, >> but as you said doing both in 1 API is probably not the best idea. >> So I believe we should park this second issue for now and revisit it >> when we find a need for it. > > Agreed. > >> Do you have any specific userspace API in mind for the >> DPTF system profile selection? > > Not really. So before /sys/power/profile was mentioned, but that seems more like a thing which should have a set of fixed possible values, iow that is out of scope for this discussion. Since we all seem to agree that this is something which we need specifically for DPTF profiles maybe just add: /sys/power/dptf_current_profile (rw) /sys/power/dptf_available_profiles (ro) (which will only be visible if a dptf-profile handler has been registered) ? Or more generic and thus better (in case other platforms later need something similar) I think, mirror the: /sys/bus/cpu/devices/cpu#/cpufreq/energy_performance_* bits for a system-wide energy-performance setting, so we get: /sys/power/energy_performance_preference /sys/power/energy_performance_available_preferences (again only visible when applicable) ? I personally like the second option best. Regards, Hans between the two, the second seems to me more appropriate. Considering that the various profiles interact with thermal behaviors what do you think of something like: /sys/power/thermal_profile_available_profiles /sys/power/thermal_profile_profile Regards, Elia I'm good with either but I do find 'profile_profile' slightly awkward to say out loud (even though it's logically correct :)) How about just: /sys/power/platform_profile /sys/power/platform_profile_available As it covers the platform as a whole - fans, temperature, power, and anything else that ends up getting thrown in? Mark
Re: [RFC] Documentation: Add documentation for new performance_profile sysfs class (Also Re: [PATCH 0/4] powercap/dtpm: Add the DTPM framework)
Hi, In data venerdì 16 ottobre 2020 13:10:54 CEST, Hans de Goede ha scritto: > from both threads to the Cc> > > Hi, > > On 10/14/20 5:42 PM, Rafael J. Wysocki wrote: > > On Wed, Oct 14, 2020 at 4:06 PM Hans de Goede wrote: > >> On 10/14/20 3:33 PM, Rafael J. Wysocki wrote: > > > >>> First, a common place to register a DPTF system profile seems to be > >>> needed and, as I said above, I wouldn't expect more than one such > >>> thing to be present in the system at any given time, so it may be > >>> registered along with the list of supported profiles and user space > >>> will have to understand what they mean. > >> > >> Mostly Ack, I would still like to have an enum for DPTF system > >> profiles in the kernel and have a single piece of code map that > >> enum to profile names. This enum can then be extended as > >> necessary, but I want to avoid having one driver use > >> "Performance" and the other "performance" or one using > >> "performance-balanced" and the other "balanced-performance", etc. > >> > >> With the goal being that new drivers use existing values from > >> the enum as much as possible, but we extend it where necessary. > > > > IOW, just a table of known profile names with specific indices assigned to > > them. > Yes. > > > This sounds reasonable. > > > >>> Second, irrespective of the above, it may be useful to have a > >>> consistent way to pass performance-vs-power preference information > >>> from user space to different parts of the kernel so as to allow them > >>> to adjust their operation and this could be done with a system-wide > >>> power profile attribute IMO. > >> > >> I agree, which is why I tried to tackle both things in one go, > >> but as you said doing both in 1 API is probably not the best idea. > >> So I believe we should park this second issue for now and revisit it > >> when we find a need for it. > > > > Agreed. > > > >> Do you have any specific userspace API in mind for the > >> DPTF system profile selection? > > > > Not really. > > So before /sys/power/profile was mentioned, but that seems more like > a thing which should have a set of fixed possible values, iow that is > out of scope for this discussion. > > Since we all seem to agree that this is something which we need > specifically for DPTF profiles maybe just add: > > /sys/power/dptf_current_profile(rw) > /sys/power/dptf_available_profiles (ro) > > (which will only be visible if a dptf-profile handler > has been registered) ? > > Or more generic and thus better (in case other platforms > later need something similar) I think, mirror the: > > /sys/bus/cpu/devices/cpu#/cpufreq/energy_performance_* bits > for a system-wide energy-performance setting, so we get: > > /sys/power/energy_performance_preference > /sys/power/energy_performance_available_preferences > > (again only visible when applicable) ? > > I personally like the second option best. > > Regards, > > Hans between the two, the second seems to me more appropriate. Considering that the various profiles interact with thermal behaviors what do you think of something like: /sys/power/thermal_profile_available_profiles /sys/power/thermal_profile_profile Regards, Elia
Re: [RFC] Documentation: Add documentation for new performance_profile sysfs class (Also Re: [PATCH 0/4] powercap/dtpm: Add the DTPM framework)
Hi, On 10/14/20 5:42 PM, Rafael J. Wysocki wrote: > On Wed, Oct 14, 2020 at 4:06 PM Hans de Goede wrote: >> On 10/14/20 3:33 PM, Rafael J. Wysocki wrote: >>> First, a common place to register a DPTF system profile seems to be >>> needed and, as I said above, I wouldn't expect more than one such >>> thing to be present in the system at any given time, so it may be >>> registered along with the list of supported profiles and user space >>> will have to understand what they mean. >> >> Mostly Ack, I would still like to have an enum for DPTF system >> profiles in the kernel and have a single piece of code map that >> enum to profile names. This enum can then be extended as >> necessary, but I want to avoid having one driver use >> "Performance" and the other "performance" or one using >> "performance-balanced" and the other "balanced-performance", etc. >> >> With the goal being that new drivers use existing values from >> the enum as much as possible, but we extend it where necessary. > > IOW, just a table of known profile names with specific indices assigned to > them. Yes. > This sounds reasonable. > >>> Second, irrespective of the above, it may be useful to have a >>> consistent way to pass performance-vs-power preference information >>> from user space to different parts of the kernel so as to allow them >>> to adjust their operation and this could be done with a system-wide >>> power profile attribute IMO. >> >> I agree, which is why I tried to tackle both things in one go, >> but as you said doing both in 1 API is probably not the best idea. >> So I believe we should park this second issue for now and revisit it >> when we find a need for it. > > Agreed. > >> Do you have any specific userspace API in mind for the >> DPTF system profile selection? > > Not really. So before /sys/power/profile was mentioned, but that seems more like a thing which should have a set of fixed possible values, iow that is out of scope for this discussion. Since we all seem to agree that this is something which we need specifically for DPTF profiles maybe just add: /sys/power/dptf_current_profile(rw) /sys/power/dptf_available_profiles (ro) (which will only be visible if a dptf-profile handler has been registered) ? Or more generic and thus better (in case other platforms later need something similar) I think, mirror the: /sys/bus/cpu/devices/cpu#/cpufreq/energy_performance_* bits for a system-wide energy-performance setting, so we get: /sys/power/energy_performance_preference /sys/power/energy_performance_available_preferences (again only visible when applicable) ? I personally like the second option best. Regards, Hans
RE: [RFC] Documentation: Add documentation for new performance_profile sysfs class
> As far as I know, the profiles affect the thermal behavior like "how long to
> wait before starting the fan and at what temperature" or "how fast to run the
> fan with the current cpu load and temperature".
>
> The only way that firmware uses to "control" performance should be the odvp0
> DPTF variable.
>
> On Windows HP expose both "Cool" and "Quiet" profile respectively as "Ideal
> for when the computer feels warm to the touch" and "Ideal for quiet
> environments".
>
> more detail: https://support.hp.com/in-en/document/c06063108
>
> To be precise "Quiet" profile should be available only on platform without
> dedicate GPU (I'm investigating if there is other case), instead the other 3
> profiles ("HP Recommended", "Performance" and "Cool") are available on all
> platform that support thermal profile.
>
> reading here seems that Dell offer identical profiles:
> https://www.dell.com/support/manuals/it/it/itbsdt1/dell-command-power-manager-
> v2.2/userguide_dell/thermal-management?guid=guid-c05d2582-fc07-4e3e-918a-
> 965836d20752=en-us
>
The Dell profiles here I don't think should be conflated with DTT/DPTF though.
These won't affect anything in the DTT vault.
Those profiles are already accessible from Linux userland, there is already a
command line tool in libsmbios that can do it.
$ sudo smbios-thermal-ctl -i
Libsmbios version : 2.4.3
smbios-thermal-ctl version : 2.4.3
Print all the Available Thermal Information of your system:
---
Supported Thermal Modes:
Balanced
Cool Bottom
Quiet
Performance
Supported Active Acoustic Controller (AAC) modes:
Supported AAC Configuration type:
Global (AAC enable/disable applies to all supported USTT modes)\
$ sudo smbios-thermal-ctl -g
Helper function to Get current Thermal Mode settings
Print Current Status of Thermal Information:
---
Current Thermal Modes:
Balanced
Current Active Acoustic Controller (AAC) Mode:
AAC mode Disabled
Current Active Acoustic Controller (AAC) Mode:
Global (AAC enable/disable applies to all supported USTT modes)
---
*If* we choose to export them for Dell from the kernel, we should probably also
filter from kernel side and modify the existing userspace tool to use the kernel
API when possible.
I'm not convinced that Dell would want to tie into this proposed knob with those
settings because I expect that existing software like thermald will not work as
efficiently.
Re: [RFC] Documentation: Add documentation for new performance_profile sysfs class
Hi, In data mercoledì 14 ottobre 2020 17:46:43 CEST, Rafael J. Wysocki ha scritto: > On Wed, Oct 14, 2020 at 4:16 PM Hans de Goede wrote: > > Hi, > > > > On 10/14/20 3:55 PM, Rafael J. Wysocki wrote: > > > On Tue, Oct 13, 2020 at 3:09 PM Hans de Goede wrote: > > >> Hi, > > >> > > >> On 10/12/20 6:42 PM, Rafael J. Wysocki wrote: > > >>> On Wed, Oct 7, 2020 at 8:41 PM Limonciello, Mario > > >>> > > >>> wrote: > > > On Wed, 2020-10-07 at 15:58 +, Limonciello, Mario wrote: > > >>> On Mon, 2020-10-05 at 12:58 +, Limonciello, Mario 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. > > > > If introducing an API for this - let me ask the question, why > > even let each > > driver offer a class interface and userspace need to change > > "each" driver's > > performance setting? > > > > I would think that you could just offer something kernel-wide > > like > > /sys/power/performance-profile > > > > Userspace can read and write to a single file. All drivers can > > get notified > > on this sysfs file changing. > > > > The systems that react in firmware (such as the two that prompted > > this discussion) can change at that time. It leaves the > > possibility for a > > more open kernel implementation that can do the same thing though > > too by > > directly modifying device registers instead of ACPI devices. > > >>> > > >>> The problem, as I've mentioned in previous discussions we had > > >>> about > > >>> this, is that, as you've seen in replies to this mail, this would > > >>> suddenly be making the kernel apply policy. > > >>> > > >>> There's going to be pushback as soon as policy is enacted in the > > >>> kernel, and you take away the different knobs for individual > > >>> components > > >>> (or you can control them centrally as well as individually). As > > >>> much as > > >>> I hate the quantity of knobs[1], I don't think that trying to > > >>> reduce > > >>> the number of knobs in the kernel is a good use of our time, and > > >>> easier > > >>> to enact, coordinated with design targets, in user-space. > > >>> > > >>> Unless you can think of a way to implement this kernel wide > > >>> setting > > >>> without adding one more exponent on the number of possibilities > > >>> for > > >>> the > > >>> testing matrix, I'll +1 Hans' original API. > > >> > > >> Actually I offered two proposals in my reply. So are you NAKing > > >> both? > > > > > > No, this is only about the first portion of the email, which I > > > quoted. > > > And I'm not NAK'ing it, but I don't see how it can work without > > > being > > > antithetical to what kernel "users" expect, or what the folks > > > consuming > > > those interfaces (presumably us both) would expect to be able to > > > test > > > and maintain. > > > > (Just so others are aware, Bastien and I had a previous discussion on > > this topic that he alluded to here: > > https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/issues > > /1) > > > > In general I agree that we shouldn't be offering 100's of knobs to > > change > > things and protect users from themselves where possible. > > > > Whether the decisions are made in the kernel or in userspace you > > still have a matrix once you're letting someone change 2 different > > kernel devices that offer policy. I'd argue it's actually worse if > > you let userspace change it though. > > > > Let's go back to the my GPU and platform example and lets say both > > offer the new knob here for both. Userspace software such as your > > PPD picks performance. Both the platform device and GPU device get > > changed, hopefully no conflicts. > > Then
Re: [RFC] Documentation: Add documentation for new performance_profile sysfs class
On Wed, Oct 14, 2020 at 4:16 PM Hans de Goede wrote: > > Hi, > > On 10/14/20 3:55 PM, Rafael J. Wysocki wrote: > > On Tue, Oct 13, 2020 at 3:09 PM Hans de Goede wrote: > >> > >> Hi, > >> > >> On 10/12/20 6:42 PM, Rafael J. Wysocki wrote: > >>> On Wed, Oct 7, 2020 at 8:41 PM Limonciello, Mario > >>> wrote: > > > On Wed, 2020-10-07 at 15:58 +, Limonciello, Mario wrote: > >> > >>> On Mon, 2020-10-05 at 12:58 +, Limonciello, Mario 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. > > > > If introducing an API for this - let me ask the question, why > even let each > driver offer a class interface and userspace need to change > "each" driver's > performance setting? > > I would think that you could just offer something kernel-wide > like > /sys/power/performance-profile > > Userspace can read and write to a single file. All drivers can > get notified > on this sysfs file changing. > > The systems that react in firmware (such as the two that prompted > this discussion) can change at that time. It leaves the > possibility for a > more open kernel implementation that can do the same thing though > too by > directly modifying device registers instead of ACPI devices. > >>> > >>> The problem, as I've mentioned in previous discussions we had about > >>> this, is that, as you've seen in replies to this mail, this would > >>> suddenly be making the kernel apply policy. > >>> > >>> There's going to be pushback as soon as policy is enacted in the > >>> kernel, and you take away the different knobs for individual > >>> components > >>> (or you can control them centrally as well as individually). As > >>> much as > >>> I hate the quantity of knobs[1], I don't think that trying to > >>> reduce > >>> the number of knobs in the kernel is a good use of our time, and > >>> easier > >>> to enact, coordinated with design targets, in user-space. > >>> > >>> Unless you can think of a way to implement this kernel wide setting > >>> without adding one more exponent on the number of possibilities for > >>> the > >>> testing matrix, I'll +1 Hans' original API. > >>> > >> Actually I offered two proposals in my reply. So are you NAKing > >> both? > > > > No, this is only about the first portion of the email, which I quoted. > > And I'm not NAK'ing it, but I don't see how it can work without being > > antithetical to what kernel "users" expect, or what the folks consuming > > those interfaces (presumably us both) would expect to be able to test > > and maintain. > > > > (Just so others are aware, Bastien and I had a previous discussion on > this topic > that he alluded to here: > https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/issues/1) > > In general I agree that we shouldn't be offering 100's of knobs to change > things and protect users from themselves where possible. > > Whether the decisions are made in the kernel or in userspace you still > have a matrix once > you're letting someone change 2 different kernel devices that offer > policy. I'd argue it's > actually worse if you let userspace change it though. > > Let's go back to the my GPU and platform example and lets say both offer > the new knob here > for both. Userspace software such as your PPD picks performance. Both > the platform device > and GPU device get changed, hopefully no conflicts. > Then user decides no, I don't want my GPU in performance mode, I only > want my platform. > So they change the knob for the GPU manually, and now you have a new > config in your matrix. > > However if you left it to a single kernel knob, both GPU and platform > get moved together and > you don't have these
Re: [RFC] Documentation: Add documentation for new performance_profile sysfs class
Hi, On 10/14/20 3:55 PM, Rafael J. Wysocki wrote: On Tue, Oct 13, 2020 at 3:09 PM Hans de Goede wrote: Hi, On 10/12/20 6:42 PM, Rafael J. Wysocki wrote: On Wed, Oct 7, 2020 at 8:41 PM Limonciello, Mario wrote: On Wed, 2020-10-07 at 15:58 +, Limonciello, Mario wrote: On Mon, 2020-10-05 at 12:58 +, Limonciello, Mario 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. If introducing an API for this - let me ask the question, why even let each driver offer a class interface and userspace need to change "each" driver's performance setting? I would think that you could just offer something kernel-wide like /sys/power/performance-profile Userspace can read and write to a single file. All drivers can get notified on this sysfs file changing. The systems that react in firmware (such as the two that prompted this discussion) can change at that time. It leaves the possibility for a more open kernel implementation that can do the same thing though too by directly modifying device registers instead of ACPI devices. The problem, as I've mentioned in previous discussions we had about this, is that, as you've seen in replies to this mail, this would suddenly be making the kernel apply policy. There's going to be pushback as soon as policy is enacted in the kernel, and you take away the different knobs for individual components (or you can control them centrally as well as individually). As much as I hate the quantity of knobs[1], I don't think that trying to reduce the number of knobs in the kernel is a good use of our time, and easier to enact, coordinated with design targets, in user-space. Unless you can think of a way to implement this kernel wide setting without adding one more exponent on the number of possibilities for the testing matrix, I'll +1 Hans' original API. Actually I offered two proposals in my reply. So are you NAKing both? No, this is only about the first portion of the email, which I quoted. And I'm not NAK'ing it, but I don't see how it can work without being antithetical to what kernel "users" expect, or what the folks consuming those interfaces (presumably us both) would expect to be able to test and maintain. (Just so others are aware, Bastien and I had a previous discussion on this topic that he alluded to here: https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/issues/1) In general I agree that we shouldn't be offering 100's of knobs to change things and protect users from themselves where possible. Whether the decisions are made in the kernel or in userspace you still have a matrix once you're letting someone change 2 different kernel devices that offer policy. I'd argue it's actually worse if you let userspace change it though. Let's go back to the my GPU and platform example and lets say both offer the new knob here for both. Userspace software such as your PPD picks performance. Both the platform device and GPU device get changed, hopefully no conflicts. Then user decides no, I don't want my GPU in performance mode, I only want my platform. So they change the knob for the GPU manually, and now you have a new config in your matrix. However if you left it to a single kernel knob, both GPU and platform get moved together and you don't have these extra configs in your matrix anymore. The other point I mentioned, that platform might also do something to GPU via a sideband and you race, you can solve it with kernel too by modifying the ordering the kernel handles it. Userspace however, you give two knobs and now you have to worry about them getting it right and supporting them doing them in the wrong order. The other one suggested to use the same firmware attributes class being introduced by the new Dell driver ( https://patchwork.kernel.org/patch/11818343/) since this is actually a knob to a specific firmware setting. This seemed to me like an implementation detail (eg. the same metadata is being exported, but in a different way), and I don't feel strongly about it either way. OK thanks. IMV there are two choices here: One is between exposing the low-level interfaces verbatim to user space and wrapping them up into a certain "translation" layer allowing user space to use a unified interface (I think that is what everybody wants) and the other boils down to how the unified interface between the kernel and
Re: [RFC] Documentation: Add documentation for new performance_profile sysfs class
On Tue, Oct 13, 2020 at 3:09 PM Hans de Goede wrote: > > Hi, > > On 10/12/20 6:42 PM, Rafael J. Wysocki wrote: > > On Wed, Oct 7, 2020 at 8:41 PM Limonciello, Mario > > wrote: > >> > >>> On Wed, 2020-10-07 at 15:58 +, Limonciello, Mario wrote: > > > On Mon, 2020-10-05 at 12:58 +, Limonciello, Mario 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. > >>> > >> > >> If introducing an API for this - let me ask the question, why > >> even let each > >> driver offer a class interface and userspace need to change > >> "each" driver's > >> performance setting? > >> > >> I would think that you could just offer something kernel-wide > >> like > >> /sys/power/performance-profile > >> > >> Userspace can read and write to a single file. All drivers can > >> get notified > >> on this sysfs file changing. > >> > >> The systems that react in firmware (such as the two that prompted > >> this discussion) can change at that time. It leaves the > >> possibility for a > >> more open kernel implementation that can do the same thing though > >> too by > >> directly modifying device registers instead of ACPI devices. > > > > The problem, as I've mentioned in previous discussions we had about > > this, is that, as you've seen in replies to this mail, this would > > suddenly be making the kernel apply policy. > > > > There's going to be pushback as soon as policy is enacted in the > > kernel, and you take away the different knobs for individual > > components > > (or you can control them centrally as well as individually). As > > much as > > I hate the quantity of knobs[1], I don't think that trying to > > reduce > > the number of knobs in the kernel is a good use of our time, and > > easier > > to enact, coordinated with design targets, in user-space. > > > > Unless you can think of a way to implement this kernel wide setting > > without adding one more exponent on the number of possibilities for > > the > > testing matrix, I'll +1 Hans' original API. > > > Actually I offered two proposals in my reply. So are you NAKing > both? > >>> > >>> No, this is only about the first portion of the email, which I quoted. > >>> And I'm not NAK'ing it, but I don't see how it can work without being > >>> antithetical to what kernel "users" expect, or what the folks consuming > >>> those interfaces (presumably us both) would expect to be able to test > >>> and maintain. > >>> > >> > >> (Just so others are aware, Bastien and I had a previous discussion on this > >> topic > >> that he alluded to here: > >> https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/issues/1) > >> > >> In general I agree that we shouldn't be offering 100's of knobs to change > >> things and protect users from themselves where possible. > >> > >> Whether the decisions are made in the kernel or in userspace you still > >> have a matrix once > >> you're letting someone change 2 different kernel devices that offer > >> policy. I'd argue it's > >> actually worse if you let userspace change it though. > >> > >> Let's go back to the my GPU and platform example and lets say both offer > >> the new knob here > >> for both. Userspace software such as your PPD picks performance. Both > >> the platform device > >> and GPU device get changed, hopefully no conflicts. > >> Then user decides no, I don't want my GPU in performance mode, I only want > >> my platform. > >> So they change the knob for the GPU manually, and now you have a new > >> config in your matrix. > >> > >> However if you left it to a single kernel knob, both GPU and platform get > >> moved together and > >> you don't have these extra configs in your matrix anymore. > >> > >> The other point I mentioned, that platform might also do something to GPU > >> via a sideband and > >> you race, you can solve it with kernel too by modifying the ordering the > >> kernel handles it. > >> > >> Userspace however, you give two knobs and now you have to worry about them > >>
Re: [RFC] Documentation: Add documentation for new performance_profile sysfs class
Hi, On 10/12/20 6:42 PM, Rafael J. Wysocki wrote: On Wed, Oct 7, 2020 at 8:41 PM Limonciello, Mario wrote: On Wed, 2020-10-07 at 15:58 +, Limonciello, Mario wrote: On Mon, 2020-10-05 at 12:58 +, Limonciello, Mario 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. If introducing an API for this - let me ask the question, why even let each driver offer a class interface and userspace need to change "each" driver's performance setting? I would think that you could just offer something kernel-wide like /sys/power/performance-profile Userspace can read and write to a single file. All drivers can get notified on this sysfs file changing. The systems that react in firmware (such as the two that prompted this discussion) can change at that time. It leaves the possibility for a more open kernel implementation that can do the same thing though too by directly modifying device registers instead of ACPI devices. The problem, as I've mentioned in previous discussions we had about this, is that, as you've seen in replies to this mail, this would suddenly be making the kernel apply policy. There's going to be pushback as soon as policy is enacted in the kernel, and you take away the different knobs for individual components (or you can control them centrally as well as individually). As much as I hate the quantity of knobs[1], I don't think that trying to reduce the number of knobs in the kernel is a good use of our time, and easier to enact, coordinated with design targets, in user-space. Unless you can think of a way to implement this kernel wide setting without adding one more exponent on the number of possibilities for the testing matrix, I'll +1 Hans' original API. Actually I offered two proposals in my reply. So are you NAKing both? No, this is only about the first portion of the email, which I quoted. And I'm not NAK'ing it, but I don't see how it can work without being antithetical to what kernel "users" expect, or what the folks consuming those interfaces (presumably us both) would expect to be able to test and maintain. (Just so others are aware, Bastien and I had a previous discussion on this topic that he alluded to here: https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/issues/1) In general I agree that we shouldn't be offering 100's of knobs to change things and protect users from themselves where possible. Whether the decisions are made in the kernel or in userspace you still have a matrix once you're letting someone change 2 different kernel devices that offer policy. I'd argue it's actually worse if you let userspace change it though. Let's go back to the my GPU and platform example and lets say both offer the new knob here for both. Userspace software such as your PPD picks performance. Both the platform device and GPU device get changed, hopefully no conflicts. Then user decides no, I don't want my GPU in performance mode, I only want my platform. So they change the knob for the GPU manually, and now you have a new config in your matrix. However if you left it to a single kernel knob, both GPU and platform get moved together and you don't have these extra configs in your matrix anymore. The other point I mentioned, that platform might also do something to GPU via a sideband and you race, you can solve it with kernel too by modifying the ordering the kernel handles it. Userspace however, you give two knobs and now you have to worry about them getting it right and supporting them doing them in the wrong order. The other one suggested to use the same firmware attributes class being introduced by the new Dell driver ( https://patchwork.kernel.org/patch/11818343/) since this is actually a knob to a specific firmware setting. This seemed to me like an implementation detail (eg. the same metadata is being exported, but in a different way), and I don't feel strongly about it either way. OK thanks. IMV there are two choices here: One is between exposing the low-level interfaces verbatim to user space and wrapping them up into a certain "translation" layer allowing user space to use a unified interface (I think that is what everybody wants) and the other boils down to how the unified interface between the kernel and user space will look like. Personally, I think that something line /sys/power/profile allowing drivers (and
Re: [RFC] Documentation: Add documentation for new performance_profile sysfs class
On Wed, Oct 7, 2020 at 8:41 PM Limonciello, Mario wrote: > > > On Wed, 2020-10-07 at 15:58 +, Limonciello, Mario wrote: > > > > > > > On Mon, 2020-10-05 at 12:58 +, Limonciello, Mario 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. > > > > > > > > > > > > > > > > If introducing an API for this - let me ask the question, why > > > > > even let each > > > > > driver offer a class interface and userspace need to change > > > > > "each" driver's > > > > > performance setting? > > > > > > > > > > I would think that you could just offer something kernel-wide > > > > > like > > > > > /sys/power/performance-profile > > > > > > > > > > Userspace can read and write to a single file. All drivers can > > > > > get notified > > > > > on this sysfs file changing. > > > > > > > > > > The systems that react in firmware (such as the two that prompted > > > > > this discussion) can change at that time. It leaves the > > > > > possibility for a > > > > > more open kernel implementation that can do the same thing though > > > > > too by > > > > > directly modifying device registers instead of ACPI devices. > > > > > > > > The problem, as I've mentioned in previous discussions we had about > > > > this, is that, as you've seen in replies to this mail, this would > > > > suddenly be making the kernel apply policy. > > > > > > > > There's going to be pushback as soon as policy is enacted in the > > > > kernel, and you take away the different knobs for individual > > > > components > > > > (or you can control them centrally as well as individually). As > > > > much as > > > > I hate the quantity of knobs[1], I don't think that trying to > > > > reduce > > > > the number of knobs in the kernel is a good use of our time, and > > > > easier > > > > to enact, coordinated with design targets, in user-space. > > > > > > > > Unless you can think of a way to implement this kernel wide setting > > > > without adding one more exponent on the number of possibilities for > > > > the > > > > testing matrix, I'll +1 Hans' original API. > > > > > > > Actually I offered two proposals in my reply. So are you NAKing > > > both? > > > > No, this is only about the first portion of the email, which I quoted. > > And I'm not NAK'ing it, but I don't see how it can work without being > > antithetical to what kernel "users" expect, or what the folks consuming > > those interfaces (presumably us both) would expect to be able to test > > and maintain. > > > > (Just so others are aware, Bastien and I had a previous discussion on this > topic > that he alluded to here: > https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/issues/1) > > In general I agree that we shouldn't be offering 100's of knobs to change > things and protect users from themselves where possible. > > Whether the decisions are made in the kernel or in userspace you still have a > matrix once > you're letting someone change 2 different kernel devices that offer policy. > I'd argue it's > actually worse if you let userspace change it though. > > Let's go back to the my GPU and platform example and lets say both offer the > new knob here > for both. Userspace software such as your PPD picks performance. Both the > platform device > and GPU device get changed, hopefully no conflicts. > Then user decides no, I don't want my GPU in performance mode, I only want my > platform. > So they change the knob for the GPU manually, and now you have a new config > in your matrix. > > However if you left it to a single kernel knob, both GPU and platform get > moved together and > you don't have these extra configs in your matrix anymore. > > The other point I mentioned, that platform might also do something to GPU via > a sideband and > you race, you can solve it with kernel too by modifying the ordering the > kernel handles it. > > Userspace however, you give two knobs and now you have to worry about them > getting it right > and supporting them doing them in the wrong order. > > > > The other one suggested to use the same firmware attributes class > > > being > > > introduced by the new
Re: [RFC] Documentation: Add documentation for new performance_profile sysfs class
Hi, On 10/5/20 2:58 PM, Limonciello, Mario 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. If introducing an API for this - let me ask the question, why even let each driver offer a class interface and userspace need to change "each" driver's performance setting? I would think that you could just offer something kernel-wide like /sys/power/performance-profile Userspace can read and write to a single file. All drivers can get notified on this sysfs file changing. In the case of the currently intended users of this API there will be only 1 provider (using the system type). So that pretty much does what you suggest. But I can see there being multiple components in a system which each can have their own performance-profile. E.g. in some desktop cases the CPU and GPU may be in separate compartments of the case which each have their own independent airflow (and thus cooling budget). Some components may even have their own air cooling with their own external radiator. So given the (potential) case with multiple components with each their own thermal-profile. Then exporting only a single setting for all components combined has 2 problems: That would mean either some complicated policy in the kernel for this, or a simple one where we set them all to the same level. The simple policy has a number of issues: 1. Setting all components to the same level assume they have identical profile options, but one component might offer low-power, while another component does not offer that (the other component could instead e.g. only offer quiet which is not 100% the same). 2. It is a given that some power users will be wanting to be able to control the profiles of different components separately, so having just a simply/naive policy in the kernel for this is not going to work for all use-cases. That leaves doing some complex policy mechanism, but in general where possible the kernel tries to stay out of enforcing policies, instead (where possible) it is greatly preferred to only offer a mechanism to allow the functionality and then let userspace handle any policy decisions. So I believe that having 1 class device for each component which offers selectable performance profiles is best. Note that something like the performance-profile-daemon Bastien is working on might very will choice to implement a KISS policy where all components get configured with a similar performance-profile, resulting in what you are suggesting. But at least this way leaves the possibility to do things differently open. Cc: Mark Pearson Cc: Elia Devito Cc: Bastien Nocera Cc: Benjamin Berg Cc: linux...@vger.kernel.org Cc: linux-a...@vger.kernel.org Signed-off-by: Hans de Goede --- .../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 ..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). Are you intending to word this specifically to cover both firmware and userspace implementations? Or were you really meaning firmware implementations? What I'm trying to cover here is both firmware (run by say some microcontroller/EC) implementations as well and in-kernel implementations like cpufreq and possible support for controlling GPU frequencies. Note this is intended to future proof things in case e.g. a GPU driver, where freq. control is done inside the kernel. would like to use this API. This scenario might never materialize. Userspace implementations (which seems to likely become a thing on at least ARM) I would expect to have their own API (e.g. dbus / configfile) to configure their behavior rather then making a round trip through kernel space with some virtual device exporting this sysfs API. +These auto
Re: [RFC] Documentation: Add documentation for new performance_profile sysfs class
Hi, On 10/5/20 3:13 PM, Benjamin Berg wrote: Hi, seems reasonable to me. Quite simple, but likely good enough as we are sticking to only use well known names. Just found a small typo. Benjamin On Sat, 2020-10-03 at 15:19 +0200, 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 Cc: Elia Devito Cc: Bastien Nocera Cc: Benjamin Berg Cc: linux...@vger.kernel.org Cc: linux-a...@vger.kernel.org Signed-off-by: Hans de Goede --- .../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 ..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 Typo, "new" -> "name" I suppose. Ack, fixed in my local tree. Thx. Regards, Hans + 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//available_profiles +Date: October 2020 +Contact: Hans de Goede +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 +
Re: [RFC] Documentation: Add documentation for new performance_profile sysfs class
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 Cc: Elia Devito Cc: Bastien Nocera Cc: Benjamin Berg Cc: linux...@vger.kernel.org Cc: linux-a...@vger.kernel.org Signed-off-by: Hans de Goede --- .../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 ..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// available_profiles +Date: October 2020 +Contact: Hans de Goede +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 +
RE: [RFC] Documentation: Add documentation for new performance_profile sysfs class
> On Wed, 2020-10-07 at 15:58 +, Limonciello, Mario wrote: > > > > > On Mon, 2020-10-05 at 12:58 +, Limonciello, Mario 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. > > > > > > > > > > > > > If introducing an API for this - let me ask the question, why > > > > even let each > > > > driver offer a class interface and userspace need to change > > > > "each" driver's > > > > performance setting? > > > > > > > > I would think that you could just offer something kernel-wide > > > > like > > > > /sys/power/performance-profile > > > > > > > > Userspace can read and write to a single file. All drivers can > > > > get notified > > > > on this sysfs file changing. > > > > > > > > The systems that react in firmware (such as the two that prompted > > > > this discussion) can change at that time. It leaves the > > > > possibility for a > > > > more open kernel implementation that can do the same thing though > > > > too by > > > > directly modifying device registers instead of ACPI devices. > > > > > > The problem, as I've mentioned in previous discussions we had about > > > this, is that, as you've seen in replies to this mail, this would > > > suddenly be making the kernel apply policy. > > > > > > There's going to be pushback as soon as policy is enacted in the > > > kernel, and you take away the different knobs for individual > > > components > > > (or you can control them centrally as well as individually). As > > > much as > > > I hate the quantity of knobs[1], I don't think that trying to > > > reduce > > > the number of knobs in the kernel is a good use of our time, and > > > easier > > > to enact, coordinated with design targets, in user-space. > > > > > > Unless you can think of a way to implement this kernel wide setting > > > without adding one more exponent on the number of possibilities for > > > the > > > testing matrix, I'll +1 Hans' original API. > > > > > Actually I offered two proposals in my reply. So are you NAKing > > both? > > No, this is only about the first portion of the email, which I quoted. > And I'm not NAK'ing it, but I don't see how it can work without being > antithetical to what kernel "users" expect, or what the folks consuming > those interfaces (presumably us both) would expect to be able to test > and maintain. > (Just so others are aware, Bastien and I had a previous discussion on this topic that he alluded to here: https://gitlab.freedesktop.org/hadess/power-profiles-daemon/-/issues/1) In general I agree that we shouldn't be offering 100's of knobs to change things and protect users from themselves where possible. Whether the decisions are made in the kernel or in userspace you still have a matrix once you're letting someone change 2 different kernel devices that offer policy. I'd argue it's actually worse if you let userspace change it though. Let's go back to the my GPU and platform example and lets say both offer the new knob here for both. Userspace software such as your PPD picks performance. Both the platform device and GPU device get changed, hopefully no conflicts. Then user decides no, I don't want my GPU in performance mode, I only want my platform. So they change the knob for the GPU manually, and now you have a new config in your matrix. However if you left it to a single kernel knob, both GPU and platform get moved together and you don't have these extra configs in your matrix anymore. The other point I mentioned, that platform might also do something to GPU via a sideband and you race, you can solve it with kernel too by modifying the ordering the kernel handles it. Userspace however, you give two knobs and now you have to worry about them getting it right and supporting them doing them in the wrong order. > > The other one suggested to use the same firmware attributes class > > being > > introduced by the new Dell driver ( > > https://patchwork.kernel.org/patch/11818343/) > > since this is actually a knob to a specific firmware setting. > > This seemed to me like an implementation detail (eg. the same metadata > is being exported, but in a different way), and I don't feel strongly > about it
Re: [RFC] Documentation: Add documentation for new performance_profile sysfs class
On Wed, 2020-10-07 at 15:58 +, Limonciello, Mario wrote: > > > On Mon, 2020-10-05 at 12:58 +, Limonciello, Mario 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. > > > > > > > > > > If introducing an API for this - let me ask the question, why > > > even let each > > > driver offer a class interface and userspace need to change > > > "each" driver's > > > performance setting? > > > > > > I would think that you could just offer something kernel-wide > > > like > > > /sys/power/performance-profile > > > > > > Userspace can read and write to a single file. All drivers can > > > get notified > > > on this sysfs file changing. > > > > > > The systems that react in firmware (such as the two that prompted > > > this discussion) can change at that time. It leaves the > > > possibility for a > > > more open kernel implementation that can do the same thing though > > > too by > > > directly modifying device registers instead of ACPI devices. > > > > The problem, as I've mentioned in previous discussions we had about > > this, is that, as you've seen in replies to this mail, this would > > suddenly be making the kernel apply policy. > > > > There's going to be pushback as soon as policy is enacted in the > > kernel, and you take away the different knobs for individual > > components > > (or you can control them centrally as well as individually). As > > much as > > I hate the quantity of knobs[1], I don't think that trying to > > reduce > > the number of knobs in the kernel is a good use of our time, and > > easier > > to enact, coordinated with design targets, in user-space. > > > > Unless you can think of a way to implement this kernel wide setting > > without adding one more exponent on the number of possibilities for > > the > > testing matrix, I'll +1 Hans' original API. > > > Actually I offered two proposals in my reply. So are you NAKing > both? No, this is only about the first portion of the email, which I quoted. And I'm not NAK'ing it, but I don't see how it can work without being antithetical to what kernel "users" expect, or what the folks consuming those interfaces (presumably us both) would expect to be able to test and maintain. > The other one suggested to use the same firmware attributes class > being > introduced by the new Dell driver ( > https://patchwork.kernel.org/patch/11818343/) > since this is actually a knob to a specific firmware setting. This seemed to me like an implementation detail (eg. the same metadata is being exported, but in a different way), and I don't feel strongly about it either way.
RE: [RFC] Documentation: Add documentation for new performance_profile sysfs class
> On Mon, 2020-10-05 at 12:58 +, Limonciello, Mario 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. > > > > > > > If introducing an API for this - let me ask the question, why even let each > > driver offer a class interface and userspace need to change "each" driver's > > performance setting? > > > > I would think that you could just offer something kernel-wide like > > /sys/power/performance-profile > > > > Userspace can read and write to a single file. All drivers can get notified > > on this sysfs file changing. > > > > The systems that react in firmware (such as the two that prompted > > this discussion) can change at that time. It leaves the possibility for a > > more open kernel implementation that can do the same thing though too by > > directly modifying device registers instead of ACPI devices. > > The problem, as I've mentioned in previous discussions we had about > this, is that, as you've seen in replies to this mail, this would > suddenly be making the kernel apply policy. > > There's going to be pushback as soon as policy is enacted in the > kernel, and you take away the different knobs for individual components > (or you can control them centrally as well as individually). As much as > I hate the quantity of knobs[1], I don't think that trying to reduce > the number of knobs in the kernel is a good use of our time, and easier > to enact, coordinated with design targets, in user-space. > > Unless you can think of a way to implement this kernel wide setting > without adding one more exponent on the number of possibilities for the > testing matrix, I'll +1 Hans' original API. > Actually I offered two proposals in my reply. So are you NAKing both? The other one suggested to use the same firmware attributes class being introduced by the new Dell driver (https://patchwork.kernel.org/patch/11818343/) since this is actually a knob to a specific firmware setting.
Re: [RFC] Documentation: Add documentation for new performance_profile sysfs class
On Mon, 2020-10-05 at 12:58 +, Limonciello, Mario 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. > > > > If introducing an API for this - let me ask the question, why even let each > driver offer a class interface and userspace need to change "each" driver's > performance setting? > > I would think that you could just offer something kernel-wide like > /sys/power/performance-profile > > Userspace can read and write to a single file. All drivers can get notified > on this sysfs file changing. > > The systems that react in firmware (such as the two that prompted > this discussion) can change at that time. It leaves the possibility for a > more open kernel implementation that can do the same thing though too by > directly modifying device registers instead of ACPI devices. The problem, as I've mentioned in previous discussions we had about this, is that, as you've seen in replies to this mail, this would suddenly be making the kernel apply policy. There's going to be pushback as soon as policy is enacted in the kernel, and you take away the different knobs for individual components (or you can control them centrally as well as individually). As much as I hate the quantity of knobs[1], I don't think that trying to reduce the number of knobs in the kernel is a good use of our time, and easier to enact, coordinated with design targets, in user-space. Unless you can think of a way to implement this kernel wide setting without adding one more exponent on the number of possibilities for the testing matrix, I'll +1 Hans' original API. Cheers [1]: https://ometer.com/preferences.html
Re: [External] RE: [RFC] Documentation: Add documentation for new performance_profile sysfs class
On 2020-10-05 12:56 p.m., Limonciello, Mario wrote: When implemented for the two vendors mentioned here, it would be using a proprietary "firmware API" implemented by those two vendors. For example write arguments (0x1, 0x2) to ACPI-WMI method WMFT and it will cause firmware to coordinate using undisclosed protocol to affect the platform changes desirable. This is different in my mind from "kernel writes to a specific register" to set power properties of a specific device. Just curious on this point - isn't that (mostly) what all hardware does? You write to it and the device does "stuff" to achieve the required effect. Yes this is in proprietary firmware, but from my experience with hardware devices that's not uncommon these days anyway. Yes I agree. Even "register" writes to a device are actually an API and something in the hardware monitors those registers and does something as a result. Let me know if I'm misunderstanding something here. I couldn't see the difference between a register written to via ACPI and one written to via some other protocol (SMBUS? or whatever) Mark The reason I'm calling out a distinction here is that "platform" and "device" can cover a lot more things. In this case it's an API provided by the platform's firmware, not an individual device's firmware. So you can't actually guarantee what the platform's firmware did. It could have sent any number of sideband commands to devices that it controls. The "platform" could have potentially told the GPU to turn up its fans, or lower it's clock as a result of this, but you can't possibly know. However if we go the GPU example alone, it's a specific single device you're controlling. You put the GPU into the characterization that you expected and it operates that way. Got it - fair enough :) Thanks for the explain. Thanks Mark
RE: [External] RE: [RFC] Documentation: Add documentation for new performance_profile sysfs class
> On 2020-10-05 12:11 p.m., Limonciello, Mario wrote: > >> > >> Excuse my ignorance, but I don't really see why this interface would be > tied > >> to > >> ACPI devices? Why is it not possible to write a driver that implements this > >> interface > >> and directly modifies device registers? Am I missing something obvious > here? > >> > > > > When implemented for the two vendors mentioned here, it would be using a > > proprietary "firmware API" implemented by those two vendors. For example > write > > arguments (0x1, 0x2) to ACPI-WMI method WMFT and it will cause firmware to > coordinate > > using undisclosed protocol to affect the platform changes desirable. > > > > This is different in my mind from "kernel writes to a specific register" to > set > > power properties of a specific device. > > > > Just curious on this point - isn't that (mostly) what all hardware does? > You write to it and the device does "stuff" to achieve the required > effect. Yes this is in proprietary firmware, but from my experience with > hardware devices that's not uncommon these days anyway. > Yes I agree. Even "register" writes to a device are actually an API and something in the hardware monitors those registers and does something as a result. > Let me know if I'm misunderstanding something here. I couldn't see the > difference between a register written to via ACPI and one written to via > some other protocol (SMBUS? or whatever) > > Mark > The reason I'm calling out a distinction here is that "platform" and "device" can cover a lot more things. In this case it's an API provided by the platform's firmware, not an individual device's firmware. So you can't actually guarantee what the platform's firmware did. It could have sent any number of sideband commands to devices that it controls. The "platform" could have potentially told the GPU to turn up its fans, or lower it's clock as a result of this, but you can't possibly know. However if we go the GPU example alone, it's a specific single device you're controlling. You put the GPU into the characterization that you expected and it operates that way.
Re: [External] RE: [RFC] Documentation: Add documentation for new performance_profile sysfs class
On 2020-10-05 12:11 p.m., Limonciello, Mario wrote: Excuse my ignorance, but I don't really see why this interface would be tied to ACPI devices? Why is it not possible to write a driver that implements this interface and directly modifies device registers? Am I missing something obvious here? When implemented for the two vendors mentioned here, it would be using a proprietary "firmware API" implemented by those two vendors. For example write arguments (0x1, 0x2) to ACPI-WMI method WMFT and it will cause firmware to coordinate using undisclosed protocol to affect the platform changes desirable. This is different in my mind from "kernel writes to a specific register" to set power properties of a specific device. Just curious on this point - isn't that (mostly) what all hardware does? You write to it and the device does "stuff" to achieve the required effect. Yes this is in proprietary firmware, but from my experience with hardware devices that's not uncommon these days anyway. Let me know if I'm misunderstanding something here. I couldn't see the difference between a register written to via ACPI and one written to via some other protocol (SMBUS? or whatever) Mark
RE: [RFC] Documentation: Add documentation for new performance_profile sysfs class
> 2020. október 5., hétfő 14:58 keltezéssel, Limonciello, Mario írta: > > > 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. > > > > If introducing an API for this - let me ask the question, why even let each > > driver offer a class interface and userspace need to change "each" driver's > > performance setting? > > > > I would think that you could just offer something kernel-wide like > > /sys/power/performance-profile > > > > Userspace can read and write to a single file. All drivers can get notified > > on this sysfs file changing. > > > > That makes sense, in my opinion, from the regular user's perspective: > one switch to rule them all, no fuss. However, I don't think that scales well. > What if the hypothetical users wants to run a CPU-heavy workload, and thus > wants > to put the GPU into "low-power" mode and the CPU into "performance" mode? What > if > the users wants to put one GPU into "low-power" mode, but the other one into > "performance"? With the current specification, the user's needs could be > easily > satisfied. I don't see how that's possible with a single switch. Nonetheless, > I think > that a single global switch *in addition* to the class devices could possibly > simplify the userspace-kernel interaction for most users. I think that the moment you represent a platform/system device as a switch you lose the ability to set different policies for other types of devices separately. What if using the platform/system device actually /also/ orchestrates changes to those other devices you mention? Then it becomes an order of events problem, or worse a problem where one switch shows "wrong" value. > > > > The systems that react in firmware (such as the two that prompted > > this discussion) can change at that time. It leaves the possibility for a > > more open kernel implementation that can do the same thing though too by > > directly modifying device registers instead of ACPI devices. > > > > Excuse my ignorance, but I don't really see why this interface would be tied > to > ACPI devices? Why is it not possible to write a driver that implements this > interface > and directly modifies device registers? Am I missing something obvious here? > When implemented for the two vendors mentioned here, it would be using a proprietary "firmware API" implemented by those two vendors. For example write arguments (0x1, 0x2) to ACPI-WMI method WMFT and it will cause firmware to coordinate using undisclosed protocol to affect the platform changes desirable. This is different in my mind from "kernel writes to a specific register" to set power properties of a specific device.
RE: [RFC] Documentation: Add documentation for new performance_profile sysfs class
Hi 2020. október 5., hétfő 14:58 keltezéssel, Limonciello, Mario írta: > > 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. > > If introducing an API for this - let me ask the question, why even let each > driver offer a class interface and userspace need to change "each" driver's > performance setting? > > I would think that you could just offer something kernel-wide like > /sys/power/performance-profile > > Userspace can read and write to a single file. All drivers can get notified > on this sysfs file changing. > That makes sense, in my opinion, from the regular user's perspective: one switch to rule them all, no fuss. However, I don't think that scales well. What if the hypothetical users wants to run a CPU-heavy workload, and thus wants to put the GPU into "low-power" mode and the CPU into "performance" mode? What if the users wants to put one GPU into "low-power" mode, but the other one into "performance"? With the current specification, the user's needs could be easily satisfied. I don't see how that's possible with a single switch. Nonetheless, I think that a single global switch *in addition* to the class devices could possibly simplify the userspace-kernel interaction for most users. > The systems that react in firmware (such as the two that prompted > this discussion) can change at that time. It leaves the possibility for a > more open kernel implementation that can do the same thing though too by > directly modifying device registers instead of ACPI devices. > Excuse my ignorance, but I don't really see why this interface would be tied to ACPI devices? Why is it not possible to write a driver that implements this interface and directly modifies device registers? Am I missing something obvious here? > [...] Thanks, Barnabás Pőcze
RE: [RFC] Documentation: Add documentation for new performance_profile sysfs class
> 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. > If introducing an API for this - let me ask the question, why even let each driver offer a class interface and userspace need to change "each" driver's performance setting? I would think that you could just offer something kernel-wide like /sys/power/performance-profile Userspace can read and write to a single file. All drivers can get notified on this sysfs file changing. The systems that react in firmware (such as the two that prompted this discussion) can change at that time. It leaves the possibility for a more open kernel implementation that can do the same thing though too by directly modifying device registers instead of ACPI devices. > Cc: Mark Pearson > Cc: Elia Devito > Cc: Bastien Nocera > Cc: Benjamin Berg > Cc: linux...@vger.kernel.org > Cc: linux-a...@vger.kernel.org > Signed-off-by: Hans de Goede > --- > .../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 ..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). Are you intending to word this specifically to cover both firmware and userspace implementations? Or were you really meaning firmware implementations? > + > +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. Another thought that comes to mind (which is completely separate from my previous idea): Why not make this register to firmware-attributes class as being discussed in the new Dell driver? It seems like it could easily be read as: /sys/class/firmware-attributes/thinkpad-foo/attributes/PerformanceProfile/current_value /sys/class/firmware-attributes/thinkpad-foo/attributes/PerformanceProfile/possible_values > + > +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: >
Re: [RFC] Documentation: Add documentation for new performance_profile sysfs class
Hi, seems reasonable to me. Quite simple, but likely good enough as we are sticking to only use well known names. Just found a small typo. Benjamin On Sat, 2020-10-03 at 15:19 +0200, 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 > Cc: Elia Devito > Cc: Bastien Nocera > Cc: Benjamin Berg > Cc: linux...@vger.kernel.org > Cc: linux-a...@vger.kernel.org > Signed-off-by: Hans de Goede > --- > .../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 ..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 Typo, "new" -> "name" I suppose. > + 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//available_profiles > +Date:October 2020 > +Contact: Hans de Goede > +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 >
Re: [RFC] Documentation: Add documentation for new performance_profile sysfs class
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 > Cc: Elia Devito > Cc: Bastien Nocera > Cc: Benjamin Berg > Cc: linux...@vger.kernel.org > Cc: linux-a...@vger.kernel.org > Signed-off-by: Hans de Goede > --- > .../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 ..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// available_profiles > +Date: October 2020 > +Contact: Hans de Goede > +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 > +
