| Message ID | 20201006122024.14539-1-daniel.lezcano@linaro.org |
|---|---|
| Headers | show |
| Series | powercap/dtpm: Add the DTPM framework | expand |
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-hdegoede@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-hdegoede@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.
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-hdegoede@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-hdegoede@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. >
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-hdegoede@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-hdegoede@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 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 ? Regards, Hans
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-hdegoede@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-hdegoede@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 * >> 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.
On Mon, Oct 12, 2020 at 1:46 PM Hans de Goede <hdegoede@redhat.com> 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-hdegoede@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-hdegoede@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 > > 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.
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: <snip> >>> 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. <snip> >>> 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
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 <hdegoede@redhat.com> wrote: <snip> >>> 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 still offering a standardized interface for userspace to consume. Granted if userspace now actually want to set a low_power profile, we have just punted the problem to userspace but I really do not see a better solution. 2. This only works assuming that all performance-profiles are system wide. But given a big desktop case there might be very well be separate cooling zones for e.g. the CPU and the GPU and I can imagine both having separate performance-profile settings and some users will doubtlessly want to be able to control these separately ... Regards, Hans
Hi Hans, On Tue, Oct 13, 2020 at 3:04 PM Hans de Goede <hdegoede@redhat.com> 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 <hdegoede@redhat.com> wrote: > > <snip> > > >>> 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 common set of values that can be understood and acted on in a consistent way by all of the interested entities within the kernel and the latter is about passing information from user space down to a side-band power control mechanism working in its own way behind the kernel's back (and possibly poking at multiple hardware components in the platform in its own way). IMO there is no way to provide a common interface covering these two cases at the same time. > 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. Well, AFAICS, DPTF system profile interfaces coming from different OEMs will be different, but they are about side-band power control and there can be only one thing like that in a platform at the same time. > 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 still offering a standardized interface for userspace > to consume. Granted if userspace now actually want to set > a low_power profile, we have just punted the problem to userspace > but I really do not see a better solution. 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. 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. > 2. This only works assuming that all performance-profiles > are system wide. But given a big desktop case there might > be very well be separate cooling zones for e.g. the CPU > and the GPU and I can imagine both having separate > performance-profile settings and some users will doubtlessly > want to be able to control these separately ... Let's say that I'm not convinced. :-) They cannot be totally separate, because they will affect each other and making possibly conflicting adjustments needs to be avoided. Cheers!
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 <hdegoede@redhat.com> 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 <hdegoede@redhat.com> wrote: >> >> <snip> >> >>>>> 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 that the issue at hand / my reason to start a discussion surrounding this is allowing userspace to selecting the DPTF system profile. The thinkpad_acpi case at hand is not using DPTF, but that is because Lenovo decided to implement dynamic DPTF like behavior inside their embedded controller (for when running Linux) since DPTF is atm not really supported all that well under Linux and Lenovo was getting a lot of complaints about sub-optimal performance because of this. So the thinkpad_acpi solution is in essence a replacement for DPTF and it should thus use the same userspace API as other mechanisms to select DPTF system profiles. And if we limit this new userspace API solely to setting DPTF system profiles, then their will indeed be only 1 provider for this for the entire system. > The former assumes that there is a common set of values that can be > understood and acted on in a consistent way by all of the interested > entities within the kernel and the latter is about passing information > from user space down to a side-band power control mechanism working in > its own way behind the kernel's back (and possibly poking at multiple > hardware components in the platform in its own way). Ack. > IMO there is no way to provide a common interface covering these two > cases at the same time. I see your point, esp. the free form vs common set of values argument seems to be exactly what we have been going in circles about during the discussion about this so far. >> 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. > > Well, AFAICS, DPTF system profile interfaces coming from different > OEMs will be different, but they are about side-band power control and > there can be only one thing like that in a platform at the same time. Ack. >> 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 still offering a standardized interface for userspace >> to consume. Granted if userspace now actually want to set >> a low_power profile, we have just punted the problem to userspace >> but I really do not see a better solution. > > 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. > 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. Do you have any specific userspace API in mind for the DPTF system profile selection? And to get one thing out of the way, in the other thread we had some discussion about using a single attribute where a cat would result in: low-power [balanced] performance Where the [] indicate the active profile, vs having 2 sysfs attributes one ro with space-separated available (foo_available) values and one wr with the actual/current value. FWIW userspace folks have indicated they prefer the solution with 2 separate sysfs-attributes and that is also what e.g. cpufreq is currently using for governor selection. I don't really have a strong opinion either way. Regards, Hans
On Wed, Oct 14, 2020 at 4:06 PM Hans de Goede <hdegoede@redhat.com> 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 <hdegoede@redhat.com> 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 <hdegoede@redhat.com> wrote: > >> > >> <snip> > >> > >>>>> 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 that the issue at hand / my reason to start a > discussion surrounding this is allowing userspace to selecting > the DPTF system profile. > > The thinkpad_acpi case at hand is not using DPTF, but that is > because Lenovo decided to implement dynamic DPTF like behavior > inside their embedded controller (for when running Linux) since > DPTF is atm not really supported all that well under Linux and > Lenovo was getting a lot of complaints about sub-optimal > performance because of this. > > So the thinkpad_acpi solution is in essence a replacement > for DPTF and it should thus use the same userspace API as > other mechanisms to select DPTF system profiles. > > And if we limit this new userspace API solely to setting DPTF > system profiles, then their will indeed be only 1 provider for > this for the entire system. > > > The former assumes that there is a common set of values that can be > > understood and acted on in a consistent way by all of the interested > > entities within the kernel and the latter is about passing information > > from user space down to a side-band power control mechanism working in > > its own way behind the kernel's back (and possibly poking at multiple > > hardware components in the platform in its own way). > > Ack. > > > IMO there is no way to provide a common interface covering these two > > cases at the same time. > > I see your point, esp. the free form vs common set of values > argument seems to be exactly what we have been going in circles > about during the discussion about this so far. > > >> 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. > > > > Well, AFAICS, DPTF system profile interfaces coming from different > > OEMs will be different, but they are about side-band power control and > > there can be only one thing like that in a platform at the same time. > > Ack. > > >> 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 still offering a standardized interface for userspace > >> to consume. Granted if userspace now actually want to set > >> a low_power profile, we have just punted the problem to userspace > >> but I really do not see a better solution. > > > > 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. 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. > And to get one thing out of the way, in the other thread we had some > discussion about using a single attribute where a cat would result in: > > low-power [balanced] performance > > Where the [] indicate the active profile, vs having 2 sysfs attributes > one ro with space-separated available (foo_available) values and one > wr with the actual/current value. FWIW userspace folks have indicated > they prefer the solution with 2 separate sysfs-attributes and that is > also what e.g. cpufreq is currently using for governor selection. Right. It also uses that for the EPP "profiles" selection which kind of belongs to the same broad category of settings. > I don't really have a strong opinion either way. Me neither. :-) I guess from the perspective of a script accessing the interface it is somewhat more straightforward to read what is available as a white-space-separated list without the need for extra parsing. Cheers!
<note folding the 2 threads we are having on this into one, adding every 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 <hdegoede@redhat.com> wrote: >> On 10/14/20 3:33 PM, Rafael J. Wysocki wrote: <snip> >>> 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
Hi, In data venerdì 16 ottobre 2020 13:10:54 CEST, Hans de Goede ha scritto: > <note folding the 2 threads we are having on this into one, adding every 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 <hdegoede@redhat.com> wrote: > >> On 10/14/20 3:33 PM, Rafael J. Wysocki wrote: > <snip> > > >>> 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
<Note - switched my email address to my more open source non-outlook based address> On 2020-10-16 10:32 a.m., Mark Pearson wrote: > > > ------------------------------------------------------------------------ > *From:* Elia Devito <eliadevito@gmail.com> > *Sent:* October 16, 2020 10:26 > *To:* Rafael J. Wysocki <rafael@kernel.org>; Hans de Goede > <hdegoede@redhat.com> > *Cc:* Daniel Lezcano <daniel.lezcano@linaro.org>; Srinivas Pandruvada > <srinivas.pandruvada@linux.intel.com>; Lukasz Luba > <lukasz.luba@arm.com>; Linux Kernel Mailing List > <linux-kernel@vger.kernel.org>; Linux PM <linux-pm@vger.kernel.org>; > Zhang, Rui <rui.zhang@intel.com>; Bastien Nocera <hadess@hadess.net>; > Mark Pearson <mpearson@lenovo.com>; Limonciello, Mario > <Mario.Limonciello@dell.com>; Darren Hart <dvhart@infradead.org>; Andy > Shevchenko <andy@infradead.org>; Mark Gross <mgross@linux.intel.com>; > Benjamin Berg <bberg@redhat.com>; linux-acpi@vger.kernel.org > <linux-acpi@vger.kernel.org>; platform-driver-x86@vger.kernel.org > <platform-driver-x86@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: >> <note folding the 2 threads we are having on this into one, adding every 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 <hdegoede@redhat.com> wrote: >> >> On 10/14/20 3:33 PM, Rafael J. Wysocki wrote: >> <snip> >> >> >>> 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
On Fri, Oct 16, 2020 at 1:11 PM Hans de Goede <hdegoede@redhat.com> wrote: > > <note folding the 2 threads we are having on this into one, adding every 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 <hdegoede@redhat.com> wrote: > >> On 10/14/20 3:33 PM, Rafael J. Wysocki wrote: > > <snip> > > >>> 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!
Hi, In data venerdì 16 ottobre 2020 16:43:09 CEST, Mark Pearson ha scritto: > <Note - switched my email address to my more open source non-outlook > based address> > > On 2020-10-16 10:32 a.m., Mark Pearson wrote: > > ------------------------------------------------------------------------ > > *From:* Elia Devito <eliadevito@gmail.com> > > *Sent:* October 16, 2020 10:26 > > *To:* Rafael J. Wysocki <rafael@kernel.org>; Hans de Goede > > <hdegoede@redhat.com> > > *Cc:* Daniel Lezcano <daniel.lezcano@linaro.org>; Srinivas Pandruvada > > <srinivas.pandruvada@linux.intel.com>; Lukasz Luba > > <lukasz.luba@arm.com>; Linux Kernel Mailing List > > <linux-kernel@vger.kernel.org>; Linux PM <linux-pm@vger.kernel.org>; > > Zhang, Rui <rui.zhang@intel.com>; Bastien Nocera <hadess@hadess.net>; > > Mark Pearson <mpearson@lenovo.com>; Limonciello, Mario > > <Mario.Limonciello@dell.com>; Darren Hart <dvhart@infradead.org>; Andy > > Shevchenko <andy@infradead.org>; Mark Gross <mgross@linux.intel.com>; > > Benjamin Berg <bberg@redhat.com>; linux-acpi@vger.kernel.org > > <linux-acpi@vger.kernel.org>; platform-driver-x86@vger.kernel.org > > <platform-driver-x86@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: > >> <note folding the 2 threads we are having on this into one, adding every > >> 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 <hdegoede@redhat.com> wrote: > >> >> On 10/14/20 3:33 PM, Rafael J. Wysocki wrote: > >> <snip> > >> > >> >>> 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
Hi, On 10/16/20 4:51 PM, Rafael J. Wysocki wrote: > On Fri, Oct 16, 2020 at 1:11 PM Hans de Goede <hdegoede@redhat.com> wrote: >> >> <note folding the 2 threads we are having on this into one, adding every 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 <hdegoede@redhat.com> wrote: >>>> On 10/14/20 3:33 PM, Rafael J. Wysocki wrote: >> >> <snip> >> >>>>> 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-acpi@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
On Sun, Oct 18, 2020 at 11:41 AM Hans de Goede <hdegoede@redhat.com> 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 <hdegoede@redhat.com> wrote: > >> > >> <note folding the 2 threads we are having on this into one, adding every 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 <hdegoede@redhat.com> wrote: > >>>> On 10/14/20 3:33 PM, Rafael J. Wysocki wrote: > >> > >> <snip> > >> > >>>>> 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-acpi@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. Cheers!
Hi, On 10/18/20 2:31 PM, Rafael J. Wysocki wrote: > On Sun, Oct 18, 2020 at 11:41 AM Hans de Goede <hdegoede@redhat.com> 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 <hdegoede@redhat.com> wrote: >>>> >>>> <note folding the 2 threads we are having on this into one, adding every 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 <hdegoede@redhat.com> wrote: >>>>>> On 10/14/20 3:33 PM, Rafael J. Wysocki wrote: >>>> >>>> <snip> >>>> >>>>>>> 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-acpi@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 itself as platform_profile handler/provider. Rafael, any suggestions / preference for where this should be added under drivers/acpi ? In a new .c file perhaps ? 3.1 Use the code from 2 to add support for platform-profile selection in thinkpad_acpi (something for me or Mark Pearson) to do 3.2 Use the code from 2 to add support for platform-profile selection to hp-wmi 3.3 (and to other drivers in the future). An open question is who will take care of 1. and 2. Mark (Pearson) do you feel up to this? or do you want me to take care of this? Regards, Hans
Hi > On 19/10/2020 14:43, Hans de Goede <hdegoede@redhat.com> 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 <hdegoede@redhat.com> 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 <hdegoede@redhat.com> wrote: >>>>> >>>>> <note folding the 2 threads we are having on this into one, adding every 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 <hdegoede@redhat.com> wrote: >>>>>>> On 10/14/20 3:33 PM, Rafael J. Wysocki wrote: >>>>> >>>>> <snip> >>>>> >>>>>>>> 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-acpi@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 itself as platform_profile handler/provider. > > Rafael, any suggestions / preference for where this should be added under > drivers/acpi ? In a new .c file perhaps ? > > 3.1 Use the code from 2 to add support for platform-profile selection in > thinkpad_acpi (something for me or Mark Pearson) to do > 3.2 Use the code from 2 to add support for platform-profile selection > to hp-wmi > 3.3 (and to other drivers in the future). > > > An open question is who will take care of 1. and 2. Mark (Pearson) > do you feel up to this? or do you want me to take care of this? > > Regards, > > Hans > Definitely up for (2) and will happily have a go at number (1). If there's an example of something similar I can look at for reference that would be helpful :) Mark
Hi, On 10/19/20 8:49 PM, Mark Pearson wrote: > Hi > >> On 19/10/2020 14:43, Hans de Goede <hdegoede@redhat.com> 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 <hdegoede@redhat.com> 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 <hdegoede@redhat.com> wrote: >>>>>> >>>>>> <note folding the 2 threads we are having on this into one, adding every 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 <hdegoede@redhat.com> wrote: >>>>>>>> On 10/14/20 3:33 PM, Rafael J. Wysocki wrote: >>>>>> >>>>>> <snip> >>>>>> >>>>>>>>> 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-acpi@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 itself as platform_profile handler/provider. >> >> Rafael, any suggestions / preference for where this should be added under >> drivers/acpi ? In a new .c file perhaps ? >> >> 3.1 Use the code from 2 to add support for platform-profile selection in >> thinkpad_acpi (something for me or Mark Pearson) to do >> 3.2 Use the code from 2 to add support for platform-profile selection >> to hp-wmi >> 3.3 (and to other drivers in the future). >> >> >> An open question is who will take care of 1. and 2. Mark (Pearson) >> do you feel up to this? or do you want me to take care of this? >> >> Regards, >> >> Hans >> > > Definitely up for (2) and will happily have a go at number (1). > > If there's an example of something similar I can look at for reference that would be helpful :) So what I would do is something like this: 1. Create a new include/acpi/platform_profile_provider.h file and in that file define: 1.1 An enum with possible profile values (as discussed we want the driver API to use an enum (which may be extended) and then use an array with strings inside the shared code to avoid differences like "Performance" vs "performance", etc. The enum should end with something like: ACPI_PLATFORM_PROFILE_COUNT 1.2 An acpi_platform_profile_provider struct in which contains a number of function-pointers for set/get callbacks (these callbacks should get/set the enum type, not strings) a "void *user_data" (to be passed back to the callbacks) and a: "unsigned long profile_choices[BITS_TO_LONGS(ACPI_PLATFORM_PROFILE_COUNT)] member. 1.3 A function to register / unregister a platform_profile_provider 2. Add a new .c file for this under drivers/acpi which should contain the actual implementation of the API (left to you) and at least 2 global variables a "struct acpi_platform_profile_provider *profile_provider;" and a mutex protecting this. The register/unregister function should lock the mutex to protect the pointer and the register function should check that this is the first provider being registered if there already is a provider registered then -EBUSY should be returned. The register/unregister functions should also add / remove the 2 /sys/firmware/acpi/platform_profile[_choices] files. Hint for the read function of the platform_profile_choices function you should use for_each_set_bit(bit, profile_choices, ACPI_PLATFORM_PROFILE_COUNT) {} Note this is more or less what I would do (minus any changes I would come up with when implementing this), feel free to use your own judgement here. Rafael, do you have any comments on this approach ? Regards, Hans