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)

[Hans de Goede]

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)

[Rafael J. Wysocki]

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)

[Mark Pearson]

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)

[Hans de Goede]

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)

[Rafael J. Wysocki]

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)

[Hans de Goede]

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)

[Elia Devito]

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)

[Rafael J. Wysocki]

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)

[Mark Pearson]

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)

[Elia Devito]

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)

[Hans de Goede]

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: [PATCH 0/4] powercap/dtpm: Add the DTPM framework

[Rafael J. Wysocki]

On Wed, Oct 14, 2020 at 4:06 PM Hans de Goede  wrote:
>
> Hi,
>
> On 10/14/20 3:33 PM, Rafael J. Wysocki wrote:
> > Hi Hans,
> >
> > On Tue, Oct 13, 2020 at 3:04 PM Hans de Goede  wrote:
> >>
> >> Hi Rafael,
> >>
> >> On 10/12/20 6:37 PM, Rafael J. Wysocki wrote:
> >>> On Mon, Oct 12, 2020 at 1:46 PM Hans de Goede  wrote:
> >>
> >> 
> >>
> > A side note, related to your proposal, not this patch. IMO it suits
> > better to have /sys/power/profile.
> >
> > cat /sys/power/profile
> >
> > power
> > balanced_power *
> > balanced
> > balanced_performance
> > performance
> >
> > The (*) being the active profile.
> 
>  Interesting the same thing was brought up in the discussion surrounding
>  RFC which I posted.
> 
>  The downside against this approach is that it assumes that there
>  only is a single system-wide settings. AFAIK that is not always
>  the case, e.g. (AFAIK):
> 
>  1. The intel pstate driver has something like this
>    (might this be the rapl setting you mean? )
> 
>  2. The X1C8 has such a setting for the embedded-controller, controlled
>    through the ACPI interfaces which thinkpad-acpi used
> 
>  3. The hp-wmi interface allows selecting a profile which in turn
>    (through AML code) sets a bunch of variables which influence how
>    the (dynamic, through mjg59's patches) DPTF code controls various
>    things
> 
>  At least the pstate setting and the vendor specific settings can
>  co-exist. Also the powercap API has a notion of zones, I can see the
>  same thing here, with a desktop e.g. having separate performance-profile
>  selection for the CPU and a discrete GPU.
> 
>  So limiting the API to a single /sys/power/profile setting seems a
>  bit limited and I have the feeling we will regret making this
>  choice in the future.
> 
>  With that said your proposal would work well for the current
>  thinkpad_acpi / hp-wmi cases, so I'm not 100% against it.
> 
>  This would require adding some internal API to the code which
>  owns the /sys/power root-dir to allow registering a profile
>  provider I guess. But that would also immediately bring the
>  question, what if multiple drivers try to register themselves
>  as /sys/power/profile provider ?
> >>>
> >>> It doesn't need to work this way IMV.
> >>>
> >>> It may also work by allowing drivers (or whatever kernel entities are
> >>> interested in that) to subscribe to it, so that they get notified
> >>> whenever a new value is written to it by user space (eg. each driver
> >>> may be able to register a callback to be invoked when that happens).
> >>> The information coming from user space will just be passed to the
> >>> subscribers of that interface and they will do about it what they want
> >>> (eg. it may be translated into a value to be written to a
> >>> performance-vs-power interface provided by the platform or similar).
> >>>
> >>> This really is similar to having a class interface with one file per
> >>> "subscribed" device except that the aggregation is done in the kernel
> >>> and not in user space and the subscribers need not be related to
> >>> specific devices.  It still allows to avoid exposing the low-level
> >>> interfaces to user space verbatim and it just passes the "policy"
> >>> choice from user space down to the entities that can take it into
> >>> account.
> >>
> >> First of all thank you for your input, with your expertise in this
> >> area your input is very much appreciated, after all we only get
> >> one chance to get the userspace API for this right.
> >>
> >> Your proposal to have a single sysfs file for userspace to talk
> >> to and then use an in kernel subscription mechanism for drivers
> >> to get notified of writes to this file is interesting.
> >>
> >> But I see 2 issues with it:
> >>
> >> 1. How will userspace know which profiles are actually available ?
> >>
> >> An obvious solution is to pick a set of standard names and let
> >> subscribers map those as close to their own settings as possible,
> >> the most often mentioned set of profile names in this case seems to be:
> >>
> >> low_power
> >> balanced_power
> >> balanced
> >> balanced_performance
> >> performance
> >>
> >> Which works fine for the thinkpad_acpi case, but not so much for
> >> the hp-wmi case. In the HP case what happens is that a WMI call
> >> is made which sets a bunch of ACPI variables which influence
> >> the DPTF code (this assumes we have some sort of DPTF support
> >> such as mjg59's reverse engineered support) but the profile-names
> >> under Windows are: "Performance", "HP recommended", "Cool" and
> >> "Quiet".  If you read the discussion from the
> >> "[RFC] Documentation: Add documentation for new performance_profile sysfs 
> >> class"
> >> thread you will see this was brought up as an issue there.
> >
> > Two different things 

Re: [PATCH 0/4] powercap/dtpm: Add the DTPM framework

[Hans de Goede]

Hi,

On 10/14/20 3:33 PM, Rafael J. Wysocki wrote:

Hi Hans,

On Tue, Oct 13, 2020 at 3:04 PM Hans de Goede  wrote:


Hi Rafael,

On 10/12/20 6:37 PM, Rafael J. Wysocki wrote:

On Mon, Oct 12, 2020 at 1:46 PM Hans de Goede  wrote:





A side note, related to your proposal, not this patch. IMO it suits
better to have /sys/power/profile.

cat /sys/power/profile

power
balanced_power *
balanced
balanced_performance
performance

The (*) being the active profile.


Interesting the same thing was brought up in the discussion surrounding
RFC which I posted.

The downside against this approach is that it assumes that there
only is a single system-wide settings. AFAIK that is not always
the case, e.g. (AFAIK):

1. The intel pstate driver has something like this
  (might this be the rapl setting you mean? )

2. The X1C8 has such a setting for the embedded-controller, controlled
  through the ACPI interfaces which thinkpad-acpi used

3. The hp-wmi interface allows selecting a profile which in turn
  (through AML code) sets a bunch of variables which influence how
  the (dynamic, through mjg59's patches) DPTF code controls various
  things

At least the pstate setting and the vendor specific settings can
co-exist. Also the powercap API has a notion of zones, I can see the
same thing here, with a desktop e.g. having separate performance-profile
selection for the CPU and a discrete GPU.

So limiting the API to a single /sys/power/profile setting seems a
bit limited and I have the feeling we will regret making this
choice in the future.

With that said your proposal would work well for the current
thinkpad_acpi / hp-wmi cases, so I'm not 100% against it.

This would require adding some internal API to the code which
owns the /sys/power root-dir to allow registering a profile
provider I guess. But that would also immediately bring the
question, what if multiple drivers try to register themselves
as /sys/power/profile provider ?


It doesn't need to work this way IMV.

It may also work by allowing drivers (or whatever kernel entities are
interested in that) to subscribe to it, so that they get notified
whenever a new value is written to it by user space (eg. each driver
may be able to register a callback to be invoked when that happens).
The information coming from user space will just be passed to the
subscribers of that interface and they will do about it what they want
(eg. it may be translated into a value to be written to a
performance-vs-power interface provided by the platform or similar).

This really is similar to having a class interface with one file per
"subscribed" device except that the aggregation is done in the kernel
and not in user space and the subscribers need not be related to
specific devices.  It still allows to avoid exposing the low-level
interfaces to user space verbatim and it just passes the "policy"
choice from user space down to the entities that can take it into
account.


First of all thank you for your input, with your expertise in this
area your input is very much appreciated, after all we only get
one chance to get the userspace API for this right.

Your proposal to have a single sysfs file for userspace to talk
to and then use an in kernel subscription mechanism for drivers
to get notified of writes to this file is interesting.

But I see 2 issues with it:

1. How will userspace know which profiles are actually available ?

An obvious solution is to pick a set of standard names and let
subscribers map those as close to their own settings as possible,
the most often mentioned set of profile names in this case seems to be:

low_power
balanced_power
balanced
balanced_performance
performance

Which works fine for the thinkpad_acpi case, but not so much for
the hp-wmi case. In the HP case what happens is that a WMI call
is made which sets a bunch of ACPI variables which influence
the DPTF code (this assumes we have some sort of DPTF support
such as mjg59's reverse engineered support) but the profile-names
under Windows are: "Performance", "HP recommended", "Cool" and
"Quiet".  If you read the discussion from the
"[RFC] Documentation: Add documentation for new performance_profile sysfs class"
thread you will see this was brought up as an issue there.


Two different things seem to be conflated here.  One is how to pass a
possible performance-vs-power preference coming from user space down
to device drivers or generally pieces of kernel code that can adjust
the behavior and/or hardware settings depending on what that
preference is and the other is how to expose OEM-provided DPTF system
profile interfaces to user space.


I was hoping / thinking that we could use a single API for both of
these. But I guess that it makes sense to see them as 2 separate
things, esp. since DPTF profiles seem to be somewhat free-form
where as a way to pass a performance-pref to a device could use
a fixes set of values.

So lets say that we indeed want to treat these 2 separately,
then I guess 

Re: [PATCH 0/4] powercap/dtpm: Add the DTPM framework

[Rafael J. Wysocki]

Hi Hans,

On Tue, Oct 13, 2020 at 3:04 PM Hans de Goede  wrote:
>
> Hi Rafael,
>
> On 10/12/20 6:37 PM, Rafael J. Wysocki wrote:
> > On Mon, Oct 12, 2020 at 1:46 PM Hans de Goede  wrote:
>
> 
>
> >>> A side note, related to your proposal, not this patch. IMO it suits
> >>> better to have /sys/power/profile.
> >>>
> >>> cat /sys/power/profile
> >>>
> >>> power
> >>> balanced_power *
> >>> balanced
> >>> balanced_performance
> >>> performance
> >>>
> >>> The (*) being the active profile.
> >>
> >> Interesting the same thing was brought up in the discussion surrounding
> >> RFC which I posted.
> >>
> >> The downside against this approach is that it assumes that there
> >> only is a single system-wide settings. AFAIK that is not always
> >> the case, e.g. (AFAIK):
> >>
> >> 1. The intel pstate driver has something like this
> >>  (might this be the rapl setting you mean? )
> >>
> >> 2. The X1C8 has such a setting for the embedded-controller, controlled
> >>  through the ACPI interfaces which thinkpad-acpi used
> >>
> >> 3. The hp-wmi interface allows selecting a profile which in turn
> >>  (through AML code) sets a bunch of variables which influence how
> >>  the (dynamic, through mjg59's patches) DPTF code controls various
> >>  things
> >>
> >> At least the pstate setting and the vendor specific settings can
> >> co-exist. Also the powercap API has a notion of zones, I can see the
> >> same thing here, with a desktop e.g. having separate performance-profile
> >> selection for the CPU and a discrete GPU.
> >>
> >> So limiting the API to a single /sys/power/profile setting seems a
> >> bit limited and I have the feeling we will regret making this
> >> choice in the future.
> >>
> >> With that said your proposal would work well for the current
> >> thinkpad_acpi / hp-wmi cases, so I'm not 100% against it.
> >>
> >> This would require adding some internal API to the code which
> >> owns the /sys/power root-dir to allow registering a profile
> >> provider I guess. But that would also immediately bring the
> >> question, what if multiple drivers try to register themselves
> >> as /sys/power/profile provider ?
> >
> > It doesn't need to work this way IMV.
> >
> > It may also work by allowing drivers (or whatever kernel entities are
> > interested in that) to subscribe to it, so that they get notified
> > whenever a new value is written to it by user space (eg. each driver
> > may be able to register a callback to be invoked when that happens).
> > The information coming from user space will just be passed to the
> > subscribers of that interface and they will do about it what they want
> > (eg. it may be translated into a value to be written to a
> > performance-vs-power interface provided by the platform or similar).
> >
> > This really is similar to having a class interface with one file per
> > "subscribed" device except that the aggregation is done in the kernel
> > and not in user space and the subscribers need not be related to
> > specific devices.  It still allows to avoid exposing the low-level
> > interfaces to user space verbatim and it just passes the "policy"
> > choice from user space down to the entities that can take it into
> > account.
>
> First of all thank you for your input, with your expertise in this
> area your input is very much appreciated, after all we only get
> one chance to get the userspace API for this right.
>
> Your proposal to have a single sysfs file for userspace to talk
> to and then use an in kernel subscription mechanism for drivers
> to get notified of writes to this file is interesting.
>
> But I see 2 issues with it:
>
> 1. How will userspace know which profiles are actually available ?
>
> An obvious solution is to pick a set of standard names and let
> subscribers map those as close to their own settings as possible,
> the most often mentioned set of profile names in this case seems to be:
>
> low_power
> balanced_power
> balanced
> balanced_performance
> performance
>
> Which works fine for the thinkpad_acpi case, but not so much for
> the hp-wmi case. In the HP case what happens is that a WMI call
> is made which sets a bunch of ACPI variables which influence
> the DPTF code (this assumes we have some sort of DPTF support
> such as mjg59's reverse engineered support) but the profile-names
> under Windows are: "Performance", "HP recommended", "Cool" and
> "Quiet".  If you read the discussion from the
> "[RFC] Documentation: Add documentation for new performance_profile sysfs 
> class"
> thread you will see this was brought up as an issue there.

Two different things seem to be conflated here.  One is how to pass a
possible performance-vs-power preference coming from user space down
to device drivers or generally pieces of kernel code that can adjust
the behavior and/or hardware settings depending on what that
preference is and the other is how to expose OEM-provided DPTF system
profile interfaces to user space.

The former assumes that there is a 

Re: [PATCH 0/4] powercap/dtpm: Add the DTPM framework

[Hans de Goede]

Hi Rafael,

On 10/12/20 6:37 PM, Rafael J. Wysocki wrote:

On Mon, Oct 12, 2020 at 1:46 PM Hans de Goede  wrote:





A side note, related to your proposal, not this patch. IMO it suits
better to have /sys/power/profile.

cat /sys/power/profile

power
balanced_power *
balanced
balanced_performance
performance

The (*) being the active profile.


Interesting the same thing was brought up in the discussion surrounding
RFC which I posted.

The downside against this approach is that it assumes that there
only is a single system-wide settings. AFAIK that is not always
the case, e.g. (AFAIK):

1. The intel pstate driver has something like this
 (might this be the rapl setting you mean? )

2. The X1C8 has such a setting for the embedded-controller, controlled
 through the ACPI interfaces which thinkpad-acpi used

3. The hp-wmi interface allows selecting a profile which in turn
 (through AML code) sets a bunch of variables which influence how
 the (dynamic, through mjg59's patches) DPTF code controls various
 things

At least the pstate setting and the vendor specific settings can
co-exist. Also the powercap API has a notion of zones, I can see the
same thing here, with a desktop e.g. having separate performance-profile
selection for the CPU and a discrete GPU.

So limiting the API to a single /sys/power/profile setting seems a
bit limited and I have the feeling we will regret making this
choice in the future.

With that said your proposal would work well for the current
thinkpad_acpi / hp-wmi cases, so I'm not 100% against it.

This would require adding some internal API to the code which
owns the /sys/power root-dir to allow registering a profile
provider I guess. But that would also immediately bring the
question, what if multiple drivers try to register themselves
as /sys/power/profile provider ?


It doesn't need to work this way IMV.

It may also work by allowing drivers (or whatever kernel entities are
interested in that) to subscribe to it, so that they get notified
whenever a new value is written to it by user space (eg. each driver
may be able to register a callback to be invoked when that happens).
The information coming from user space will just be passed to the
subscribers of that interface and they will do about it what they want
(eg. it may be translated into a value to be written to a
performance-vs-power interface provided by the platform or similar).

This really is similar to having a class interface with one file per
"subscribed" device except that the aggregation is done in the kernel
and not in user space and the subscribers need not be related to
specific devices.  It still allows to avoid exposing the low-level
interfaces to user space verbatim and it just passes the "policy"
choice from user space down to the entities that can take it into
account.


First of all thank you for your input, with your expertise in this
area your input is very much appreciated, after all we only get
one chance to get the userspace API for this right.

Your proposal to have a single sysfs file for userspace to talk
to and then use an in kernel subscription mechanism for drivers
to get notified of writes to this file is interesting.

But I see 2 issues with it:

1. How will userspace know which profiles are actually available ?

An obvious solution is to pick a set of standard names and let
subscribers map those as close to their own settings as possible,
the most often mentioned set of profile names in this case seems to be:

low_power
balanced_power
balanced
balanced_performance
performance

Which works fine for the thinkpad_acpi case, but not so much for
the hp-wmi case. In the HP case what happens is that a WMI call
is made which sets a bunch of ACPI variables which influence
the DPTF code (this assumes we have some sort of DPTF support
such as mjg59's reverse engineered support) but the profile-names
under Windows are: "Performance", "HP recommended", "Cool" and
"Quiet".  If you read the discussion from the
"[RFC] Documentation: Add documentation for new performance_profile sysfs class"
thread you will see this was brought up as an issue there.

The problem here is that both "cool" and "quiet" could be
interpreted as low-power. But it seems that they actually mean
what they say, cool focuses on keeping temps low, which can
also be done by making the fan-profile more aggressive. And quiet
is mostly about keeping fan speeds down, at the cost of possible
higher temperatures.  IOW we don't really have a 1 dimensional
axis. My class proposal fixes this by having a notion of both
standardized names (because anything else would suck) combined
with a way for drivers to advertise which standardized names
the support. So in my proposal I simply add quiet and cool
to the list of standard profile names, and then the HP-wmi
driver can list those as supported, while not listing
low_power as a supported profile.  This way we export the
hardware interface to userspace as is (as much as possible)
while 

Re: [PATCH 0/4] powercap/dtpm: Add the DTPM framework

[Hans de Goede]

Hi,

On 10/12/20 6:02 PM, Daniel Lezcano wrote:

On 12/10/2020 13:46, Hans de Goede wrote:

Hi Daniel,

On 10/12/20 12:30 PM, Daniel Lezcano wrote:





Here the proposed interface is already exported in userspace via the
powercap framework which supports today the backend driver for the RAPL
register.


You say that some sort of power/ balanced power / balanced /
balanced performance / performance setting in is already exported
through the powercap interface today (if I understand you correctly)?


Sorry, I was unclear. I meant 'Here the proposed interface' referring to
the powercap/dtpm. There is no profile interface in the powercap framework.


Ah, I see.




A side note, related to your proposal, not this patch. IMO it suits
better to have /sys/power/profile.

cat /sys/power/profile

power
balanced_power *
balanced
balanced_performance
performance

The (*) being the active profile.


Interesting the same thing was brought up in the discussion surrounding
RFC which I posted.

The downside against this approach is that it assumes that there
only is a single system-wide settings. AFAIK that is not always
the case, e.g. (AFAIK):

1. The intel pstate driver has something like this
    (might this be the rapl setting you mean? )

2. The X1C8 has such a setting for the embedded-controller, controlled
    through the ACPI interfaces which thinkpad-acpi used

3. The hp-wmi interface allows selecting a profile which in turn
    (through AML code) sets a bunch of variables which influence how
    the (dynamic, through mjg59's patches) DPTF code controls various
    things

At least the pstate setting and the vendor specific settings can
co-exist. Also the powercap API has a notion of zones, I can see the
same thing here, with a desktop e.g. having separate performance-profile
selection for the CPU and a discrete GPU.

So limiting the API to a single /sys/power/profile setting seems a
bit limited and I have the feeling we will regret making this
choice in the future.

With that said your proposal would work well for the current
thinkpad_acpi / hp-wmi cases, so I'm not 100% against it.

This would require adding some internal API to the code which
owns the /sys/power root-dir to allow registering a profile
provider I guess. But that would also immediately bring the
question, what if multiple drivers try to register themselves
as /sys/power/profile provider ?


Did you consider putting the profile on a per device basis ?

eg.

/sys/devices/system/cpu/cpu[0-9]/power/profile

May be make 'energy_performance_preference' obsolete in
/sys/devices/system/cpu/cpufreq ?

When one device sets the profile, all children will have the same profile.

eg.

A change in /sys/devices/system/cpu/power/profile will impact all the
underlying cpu[0-9]/power/profile

Or a change in /sys/devices/power/profile will change all profiles below
/sys/devices.

Well that is a high level suggestion, I don't know how that can fit with
the cyclic sysfs hierarchy.


A problem with I see with making this a per-device power setting is that
only a few devices will actually have this; and then the question becomes
how does userspace discover / find these devices ? Typically for these kinda
discovery problems we use a sysfs class as a solution to group devices
offering the same functionailty (through the same standardized sysfs API)
together. Which circles back to my original RFC proposal for this.

Regards,

Hans

Re: [PATCH 0/4] powercap/dtpm: Add the DTPM framework

[Rafael J. Wysocki]

On Mon, Oct 12, 2020 at 1:46 PM Hans de Goede  wrote:
>
> Hi Daniel,
>
> On 10/12/20 12:30 PM, Daniel Lezcano wrote:
> >
> > Hi Hans,
> >
> > On 07/10/2020 12:43, Hans de Goede wrote:
> >> Hi,
> >>
> >> On 10/6/20 2:20 PM, Daniel Lezcano wrote:
> >>> The density of components greatly increased the last decade bringing a
> >>> numerous number of heating sources which are monitored by more than 20
> >>> sensors on recent SoC. The skin temperature, which is the case
> >>> temperature of the device, must stay below approximately 45°C in order
> >>> to comply with the legal requirements.
> >>>
> >>> The skin temperature is managed as a whole by an user space daemon,
> >>> which is catching the current application profile, to allocate a power
> >>> budget to the different components where the resulting heating effect
> >>> will comply with the skin temperature constraint.
> >>>
> >>> This technique is called the Dynamic Thermal Power Management.
> >>>
> >>> The Linux kernel does not provide any unified interface to act on the
> >>> power of the different devices. Currently, the thermal framework is
> >>> changed to export artificially the performance states of different
> >>> devices via the cooling device software component with opaque values.
> >>> This change is done regardless of the in-kernel logic to mitigate the
> >>> temperature. The user space daemon uses all the available knobs to act
> >>> on the power limit and those differ from one platform to another.
> >>>
> >>> This series provides a Dynamic Thermal Power Management framework to
> >>> provide an unified way to act on the power of the devices.
> >>
> >> Interesting, we have a discussion going on about a related
> >> (while at the same time almost orthogonal) discussion for
> >> setting policies for if the code managing the restraints
> >> (which on x86 is often hidden in firmware or ACPI DPTF tables)
> >> should have a bias towards trying to have as long a battery life
> >> as possible, vs maximum performance. I know those 2 aren't
> >> always opposite ends of a spectrum with race-to-idle, yet most
> >> modern x86 hardware has some notion of what I call performance-profiles
> >> where we can tell the firmware managing this to go for a bias towards
> >> low-power / balanced / performance.
> >>
> >> I've send a RFC / sysfs API proposal for this here:
> >> https://lore.kernel.org/linux-pm/20201003131938.9426-1-hdego...@redhat.com/
> >>
> >> I've read the patches in this thread and as said already I think
> >> the 2 APIs are mostly orthogonal. The API in this thread is giving
> >> userspace direct access to detailed power-limits allowing userspace
> >> to configure things directly (and for things to work optimal userspace
> >> must do this). Where as in the x86 case with which I'm dealing everything
> >> is mostly handled in a black-box and userspace can merely configure
> >> the low-power / balanced / performance bias (*) of that black-box.
> >>
> >> Still I think it is good if we are aware of each-others efforts here.
> >>
> >> So Daniel, if you can take a quick look at my proposal:
> >> https://lore.kernel.org/linux-pm/20201003131938.9426-1-hdego...@redhat.com/
> >>
> >> That would be great. I think we definitely want to avoid having 2
> >> APIs for the same thing here. Again I don't think that is actually
> >> the case, but maybe you see this differently ?
> >
> > Thanks for pointing this out. Actually, it is a different feature as you
> > mentioned. The profile is the same knob we have with the BIOS where we
> > can choose power/ balanced power / balanced/balanced
> > performance / performance, AFAICT.
>
> Right.
>
> > Here the proposed interface is already exported in userspace via the
> > powercap framework which supports today the backend driver for the RAPL
> > register.
>
> You say that some sort of power/ balanced power / balanced /
> balanced performance / performance setting in is already exported
> through the powercap interface today (if I understand you correctly)?
>
> But I'm not seeing any such setting in:
> Documentation/ABI/testing/sysfs-class-powercap
>
> Nor can I find it under /sys/class/powercap/intel-rapl* on a ThinkPad
> X1 carbon 8th gen.
>
> Note, if there indeed is an existing userspace API for this I would
> greatly prefer for the thinkpad_acpi and hp-wmi (and possibly other)
> drivers to use this, so if you can point me to this interface then
> that would be great.
>
> > The userspace will be in charge of handling the logic to have the
> > correct power/performance profile tuned against the current application
> > running foreground. The DTPM framework gives the unified access to the
> > power limitation to the individual devices the userspace logic can act on.
> >
> > A side note, related to your proposal, not this patch. IMO it suits
> > better to have /sys/power/profile.
> >
> > cat /sys/power/profile
> >
> > power
> > balanced_power *
> > balanced
> > balanced_performance
> > performance
> >
> > The (*) being the 

Re: [PATCH 0/4] powercap/dtpm: Add the DTPM framework

[Daniel Lezcano]

On 12/10/2020 13:46, Hans de Goede wrote:
> Hi Daniel,
> 
> On 10/12/20 12:30 PM, Daniel Lezcano wrote:
>>
>> Hi Hans,
>>
>> On 07/10/2020 12:43, Hans de Goede wrote:
>>> Hi,
>>>
>>> On 10/6/20 2:20 PM, Daniel Lezcano wrote:
 The density of components greatly increased the last decade bringing a
 numerous number of heating sources which are monitored by more than 20
 sensors on recent SoC. The skin temperature, which is the case
 temperature of the device, must stay below approximately 45°C in order
 to comply with the legal requirements.

 The skin temperature is managed as a whole by an user space daemon,
 which is catching the current application profile, to allocate a power
 budget to the different components where the resulting heating effect
 will comply with the skin temperature constraint.

 This technique is called the Dynamic Thermal Power Management.

 The Linux kernel does not provide any unified interface to act on the
 power of the different devices. Currently, the thermal framework is
 changed to export artificially the performance states of different
 devices via the cooling device software component with opaque values.
 This change is done regardless of the in-kernel logic to mitigate the
 temperature. The user space daemon uses all the available knobs to act
 on the power limit and those differ from one platform to another.

 This series provides a Dynamic Thermal Power Management framework to
 provide an unified way to act on the power of the devices.
>>>
>>> Interesting, we have a discussion going on about a related
>>> (while at the same time almost orthogonal) discussion for
>>> setting policies for if the code managing the restraints
>>> (which on x86 is often hidden in firmware or ACPI DPTF tables)
>>> should have a bias towards trying to have as long a battery life
>>> as possible, vs maximum performance. I know those 2 aren't
>>> always opposite ends of a spectrum with race-to-idle, yet most
>>> modern x86 hardware has some notion of what I call performance-profiles
>>> where we can tell the firmware managing this to go for a bias towards
>>> low-power / balanced / performance.
>>>
>>> I've send a RFC / sysfs API proposal for this here:
>>> https://lore.kernel.org/linux-pm/20201003131938.9426-1-hdego...@redhat.com/
>>>
>>>
>>> I've read the patches in this thread and as said already I think
>>> the 2 APIs are mostly orthogonal. The API in this thread is giving
>>> userspace direct access to detailed power-limits allowing userspace
>>> to configure things directly (and for things to work optimal userspace
>>> must do this). Where as in the x86 case with which I'm dealing
>>> everything
>>> is mostly handled in a black-box and userspace can merely configure
>>> the low-power / balanced / performance bias (*) of that black-box.
>>>
>>> Still I think it is good if we are aware of each-others efforts here.
>>>
>>> So Daniel, if you can take a quick look at my proposal:
>>> https://lore.kernel.org/linux-pm/20201003131938.9426-1-hdego...@redhat.com/
>>>
>>>
>>> That would be great. I think we definitely want to avoid having 2
>>> APIs for the same thing here. Again I don't think that is actually
>>> the case, but maybe you see this differently ?
>>
>> Thanks for pointing this out. Actually, it is a different feature as you
>> mentioned. The profile is the same knob we have with the BIOS where we
>> can choose power/ balanced power / balanced/balanced
>> performance / performance, AFAICT.
> 
> Right.
> 
>> Here the proposed interface is already exported in userspace via the
>> powercap framework which supports today the backend driver for the RAPL
>> register.
> 
> You say that some sort of power/ balanced power / balanced /
> balanced performance / performance setting in is already exported
> through the powercap interface today (if I understand you correctly)?

Sorry, I was unclear. I meant 'Here the proposed interface' referring to
the powercap/dtpm. There is no profile interface in the powercap framework.

> But I'm not seeing any such setting in:
> Documentation/ABI/testing/sysfs-class-powercap
> 
> Nor can I find it under /sys/class/powercap/intel-rapl* on a ThinkPad
> X1 carbon 8th gen.
> 
> Note, if there indeed is an existing userspace API for this I would
> greatly prefer for the thinkpad_acpi and hp-wmi (and possibly other)
> drivers to use this, so if you can point me to this interface then
> that would be great.
> 
>> The userspace will be in charge of handling the logic to have the
>> correct power/performance profile tuned against the current application
>> running foreground. The DTPM framework gives the unified access to the
>> power limitation to the individual devices the userspace logic can act
>> on.
>>
>> A side note, related to your proposal, not this patch. IMO it suits
>> better to have /sys/power/profile.
>>
>> cat /sys/power/profile
>>
>> power
>> balanced_power *
>> 

Re: [PATCH 0/4] powercap/dtpm: Add the DTPM framework

[Hans de Goede]

Hi Daniel,

On 10/12/20 12:30 PM, Daniel Lezcano wrote:


Hi Hans,

On 07/10/2020 12:43, Hans de Goede wrote:

Hi,

On 10/6/20 2:20 PM, Daniel Lezcano wrote:

The density of components greatly increased the last decade bringing a
numerous number of heating sources which are monitored by more than 20
sensors on recent SoC. The skin temperature, which is the case
temperature of the device, must stay below approximately 45°C in order
to comply with the legal requirements.

The skin temperature is managed as a whole by an user space daemon,
which is catching the current application profile, to allocate a power
budget to the different components where the resulting heating effect
will comply with the skin temperature constraint.

This technique is called the Dynamic Thermal Power Management.

The Linux kernel does not provide any unified interface to act on the
power of the different devices. Currently, the thermal framework is
changed to export artificially the performance states of different
devices via the cooling device software component with opaque values.
This change is done regardless of the in-kernel logic to mitigate the
temperature. The user space daemon uses all the available knobs to act
on the power limit and those differ from one platform to another.

This series provides a Dynamic Thermal Power Management framework to
provide an unified way to act on the power of the devices.


Interesting, we have a discussion going on about a related
(while at the same time almost orthogonal) discussion for
setting policies for if the code managing the restraints
(which on x86 is often hidden in firmware or ACPI DPTF tables)
should have a bias towards trying to have as long a battery life
as possible, vs maximum performance. I know those 2 aren't
always opposite ends of a spectrum with race-to-idle, yet most
modern x86 hardware has some notion of what I call performance-profiles
where we can tell the firmware managing this to go for a bias towards
low-power / balanced / performance.

I've send a RFC / sysfs API proposal for this here:
https://lore.kernel.org/linux-pm/20201003131938.9426-1-hdego...@redhat.com/

I've read the patches in this thread and as said already I think
the 2 APIs are mostly orthogonal. The API in this thread is giving
userspace direct access to detailed power-limits allowing userspace
to configure things directly (and for things to work optimal userspace
must do this). Where as in the x86 case with which I'm dealing everything
is mostly handled in a black-box and userspace can merely configure
the low-power / balanced / performance bias (*) of that black-box.

Still I think it is good if we are aware of each-others efforts here.

So Daniel, if you can take a quick look at my proposal:
https://lore.kernel.org/linux-pm/20201003131938.9426-1-hdego...@redhat.com/

That would be great. I think we definitely want to avoid having 2
APIs for the same thing here. Again I don't think that is actually
the case, but maybe you see this differently ?


Thanks for pointing this out. Actually, it is a different feature as you
mentioned. The profile is the same knob we have with the BIOS where we
can choose power/ balanced power / balanced/balanced
performance / performance, AFAICT.


Right.


Here the proposed interface is already exported in userspace via the
powercap framework which supports today the backend driver for the RAPL
register.


You say that some sort of power/ balanced power / balanced /
balanced performance / performance setting in is already exported
through the powercap interface today (if I understand you correctly)?

But I'm not seeing any such setting in:
Documentation/ABI/testing/sysfs-class-powercap

Nor can I find it under /sys/class/powercap/intel-rapl* on a ThinkPad
X1 carbon 8th gen.

Note, if there indeed is an existing userspace API for this I would
greatly prefer for the thinkpad_acpi and hp-wmi (and possibly other)
drivers to use this, so if you can point me to this interface then
that would be great.


The userspace will be in charge of handling the logic to have the
correct power/performance profile tuned against the current application
running foreground. The DTPM framework gives the unified access to the
power limitation to the individual devices the userspace logic can act on.

A side note, related to your proposal, not this patch. IMO it suits
better to have /sys/power/profile.

cat /sys/power/profile

power
balanced_power *
balanced
balanced_performance
performance

The (*) being the active profile.


Interesting the same thing was brought up in the discussion surrounding
RFC which I posted.

The downside against this approach is that it assumes that there
only is a single system-wide settings. AFAIK that is not always
the case, e.g. (AFAIK):

1. The intel pstate driver has something like this
   (might this be the rapl setting you mean? )

2. The X1C8 has such a setting for the embedded-controller, controlled
   through the ACPI interfaces which thinkpad-acpi used

Re: [PATCH 0/4] powercap/dtpm: Add the DTPM framework

[Daniel Lezcano]

Hi Hans,

On 07/10/2020 12:43, Hans de Goede wrote:
> Hi,
> 
> On 10/6/20 2:20 PM, Daniel Lezcano wrote:
>> The density of components greatly increased the last decade bringing a
>> numerous number of heating sources which are monitored by more than 20
>> sensors on recent SoC. The skin temperature, which is the case
>> temperature of the device, must stay below approximately 45°C in order
>> to comply with the legal requirements.
>>
>> The skin temperature is managed as a whole by an user space daemon,
>> which is catching the current application profile, to allocate a power
>> budget to the different components where the resulting heating effect
>> will comply with the skin temperature constraint.
>>
>> This technique is called the Dynamic Thermal Power Management.
>>
>> The Linux kernel does not provide any unified interface to act on the
>> power of the different devices. Currently, the thermal framework is
>> changed to export artificially the performance states of different
>> devices via the cooling device software component with opaque values.
>> This change is done regardless of the in-kernel logic to mitigate the
>> temperature. The user space daemon uses all the available knobs to act
>> on the power limit and those differ from one platform to another.
>>
>> This series provides a Dynamic Thermal Power Management framework to
>> provide an unified way to act on the power of the devices.
> 
> Interesting, we have a discussion going on about a related
> (while at the same time almost orthogonal) discussion for
> setting policies for if the code managing the restraints
> (which on x86 is often hidden in firmware or ACPI DPTF tables)
> should have a bias towards trying to have as long a battery life
> as possible, vs maximum performance. I know those 2 aren't
> always opposite ends of a spectrum with race-to-idle, yet most
> modern x86 hardware has some notion of what I call performance-profiles
> where we can tell the firmware managing this to go for a bias towards
> low-power / balanced / performance.
> 
> I've send a RFC / sysfs API proposal for this here:
> https://lore.kernel.org/linux-pm/20201003131938.9426-1-hdego...@redhat.com/
> 
> I've read the patches in this thread and as said already I think
> the 2 APIs are mostly orthogonal. The API in this thread is giving
> userspace direct access to detailed power-limits allowing userspace
> to configure things directly (and for things to work optimal userspace
> must do this). Where as in the x86 case with which I'm dealing everything
> is mostly handled in a black-box and userspace can merely configure
> the low-power / balanced / performance bias (*) of that black-box.
> 
> Still I think it is good if we are aware of each-others efforts here.
> 
> So Daniel, if you can take a quick look at my proposal:
> https://lore.kernel.org/linux-pm/20201003131938.9426-1-hdego...@redhat.com/
> 
> That would be great. I think we definitely want to avoid having 2
> APIs for the same thing here. Again I don't think that is actually
> the case, but maybe you see this differently ?

Thanks for pointing this out. Actually, it is a different feature as you
mentioned. The profile is the same knob we have with the BIOS where we
can choose power/ balanced power / balanced/balanced
performance / performance, AFAICT.

Here the proposed interface is already exported in userspace via the
powercap framework which supports today the backend driver for the RAPL
register.

The userspace will be in charge of handling the logic to have the
correct power/performance profile tuned against the current application
running foreground. The DTPM framework gives the unified access to the
power limitation to the individual devices the userspace logic can act on.

A side note, related to your proposal, not this patch. IMO it suits
better to have /sys/power/profile.

cat /sys/power/profile

power
balanced_power *
balanced
balanced_performance
performance

The (*) being the active profile.


> *) bias might not always give the correct impression at least
> on some Thinkpads switching from balanced (which they call medium)
> to performance boosts the long time power-limit from aprox.
> 15W to 25W which as expected results in a significant performance
> boost.
> 
> Note usually we have no idea what the black-box knob which we are
> tweaking actually does, all we know is that it is there and
> Windows 10 often has a slider to configure it and users want
> the same functionality under Linux.
> 


-- 
 Linaro.org │ Open source software for ARM SoCs

Follow Linaro:   Facebook |
 Twitter |
 Blog

Re: [PATCH 0/4] powercap/dtpm: Add the DTPM framework

[Hans de Goede]

Hi,

On 10/6/20 2:20 PM, Daniel Lezcano wrote:

The density of components greatly increased the last decade bringing a
numerous number of heating sources which are monitored by more than 20
sensors on recent SoC. The skin temperature, which is the case
temperature of the device, must stay below approximately 45°C in order
to comply with the legal requirements.

The skin temperature is managed as a whole by an user space daemon,
which is catching the current application profile, to allocate a power
budget to the different components where the resulting heating effect
will comply with the skin temperature constraint.

This technique is called the Dynamic Thermal Power Management.

The Linux kernel does not provide any unified interface to act on the
power of the different devices. Currently, the thermal framework is
changed to export artificially the performance states of different
devices via the cooling device software component with opaque values.
This change is done regardless of the in-kernel logic to mitigate the
temperature. The user space daemon uses all the available knobs to act
on the power limit and those differ from one platform to another.

This series provides a Dynamic Thermal Power Management framework to
provide an unified way to act on the power of the devices.


Interesting, we have a discussion going on about a related
(while at the same time almost orthogonal) discussion for
setting policies for if the code managing the restraints
(which on x86 is often hidden in firmware or ACPI DPTF tables)
should have a bias towards trying to have as long a battery life
as possible, vs maximum performance. I know those 2 aren't
always opposite ends of a spectrum with race-to-idle, yet most
modern x86 hardware has some notion of what I call performance-profiles
where we can tell the firmware managing this to go for a bias towards
low-power / balanced / performance.

I've send a RFC / sysfs API proposal for this here:
https://lore.kernel.org/linux-pm/20201003131938.9426-1-hdego...@redhat.com/

I've read the patches in this thread and as said already I think
the 2 APIs are mostly orthogonal. The API in this thread is giving
userspace direct access to detailed power-limits allowing userspace
to configure things directly (and for things to work optimal userspace
must do this). Where as in the x86 case with which I'm dealing everything
is mostly handled in a black-box and userspace can merely configure
the low-power / balanced / performance bias (*) of that black-box.

Still I think it is good if we are aware of each-others efforts here.

So Daniel, if you can take a quick look at my proposal:
https://lore.kernel.org/linux-pm/20201003131938.9426-1-hdego...@redhat.com/

That would be great. I think we definitely want to avoid having 2
APIs for the same thing here. Again I don't think that is actually
the case, but maybe you see this differently ?

Regards,

Hans


*) bias might not always give the correct impression at least
on some Thinkpads switching from balanced (which they call medium)
to performance boosts the long time power-limit from aprox.
15W to 25W which as expected results in a significant performance
boost.

Note usually we have no idea what the black-box knob which we are
tweaking actually does, all we know is that it is there and
Windows 10 often has a slider to configure it and users want
the same functionality under Linux.

[PATCH 0/4] powercap/dtpm: Add the DTPM framework

[Daniel Lezcano]

The density of components greatly increased the last decade bringing a
numerous number of heating sources which are monitored by more than 20
sensors on recent SoC. The skin temperature, which is the case
temperature of the device, must stay below approximately 45°C in order
to comply with the legal requirements.

The skin temperature is managed as a whole by an user space daemon,
which is catching the current application profile, to allocate a power
budget to the different components where the resulting heating effect
will comply with the skin temperature constraint.

This technique is called the Dynamic Thermal Power Management.

The Linux kernel does not provide any unified interface to act on the
power of the different devices. Currently, the thermal framework is
changed to export artificially the performance states of different
devices via the cooling device software component with opaque values.
This change is done regardless of the in-kernel logic to mitigate the
temperature. The user space daemon uses all the available knobs to act
on the power limit and those differ from one platform to another.

This series provides a Dynamic Thermal Power Management framework to
provide an unified way to act on the power of the devices.

Daniel Lezcano (4):
  units: Add Watt units
  Documentation/powercap/dtpm: Add documentation for dtpm
  powercap/drivers/dtpm: Add API for dynamic thermal power management
  powercap/drivers/dtpm: Add CPU energy model based support

 Documentation/power/powercap/dtpm.rst | 222 +
 drivers/powercap/Kconfig  |  14 +
 drivers/powercap/Makefile |   2 +
 drivers/powercap/dtpm.c   | 430 ++
 drivers/powercap/dtpm_cpu.c   | 242 +++
 include/asm-generic/vmlinux.lds.h |  11 +
 include/linux/cpuhotplug.h|   1 +
 include/linux/dtpm.h  |  76 +
 include/linux/units.h |   4 +
 9 files changed, 1002 insertions(+)
 create mode 100644 Documentation/power/powercap/dtpm.rst
 create mode 100644 drivers/powercap/dtpm.c
 create mode 100644 drivers/powercap/dtpm_cpu.c
 create mode 100644 include/linux/dtpm.h

--
2.17.1