linux-pm.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Hans de Goede <hdegoede@redhat.com>,
	rafael@kernel.org, srinivas.pandruvada@linux.intel.com
Cc: lukasz.luba@arm.com, linux-kernel@vger.kernel.org,
	linux-pm@vger.kernel.org, rui.zhang@intel.com
Subject: Re: [PATCH 0/4] powercap/dtpm: Add the DTPM framework
Date: Mon, 12 Oct 2020 18:02:59 +0200	[thread overview]
Message-ID: <bc1a0134-5242-65d7-a753-fbec0d3bb327@linaro.org> (raw)
In-Reply-To: <97e5368b-228d-eca1-85a5-b918dfcfd336@redhat.com>

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.







-- 
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs

Follow Linaro:  <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog

  reply	other threads:[~2020-10-12 16:03 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-06 12:20 [PATCH 0/4] powercap/dtpm: Add the DTPM framework Daniel Lezcano
2020-10-06 12:20 ` [PATCH 1/4] units: Add Watt units Daniel Lezcano
2020-11-10 10:02   ` Lukasz Luba
2020-10-06 12:20 ` [PATCH 2/4] Documentation/powercap/dtpm: Add documentation for dtpm Daniel Lezcano
2020-10-13 22:01   ` Ram Chandrasekar
2020-10-06 12:20 ` [PATCH 3/4] powercap/drivers/dtpm: Add API for dynamic thermal power management Daniel Lezcano
2020-10-06 16:42   ` kernel test robot
2020-10-06 18:05   ` kernel test robot
2020-10-23 10:29   ` Lukasz Luba
2020-11-03 18:42     ` Daniel Lezcano
2020-11-10  9:59   ` Lukasz Luba
2020-11-10 11:05     ` Lukasz Luba
2020-11-10 14:59       ` Daniel Lezcano
2020-11-10 15:04         ` Lukasz Luba
2020-11-10 12:55     ` Daniel Lezcano
2020-10-06 12:20 ` [PATCH 4/4] powercap/drivers/dtpm: Add CPU energy model based support Daniel Lezcano
2020-10-23 13:27   ` Lukasz Luba
2020-11-04 10:47     ` Daniel Lezcano
2020-11-04 10:57       ` Lukasz Luba
2020-11-04 11:15         ` Daniel Lezcano
2020-11-10 12:50   ` Lukasz Luba
2020-10-07 10:43 ` [PATCH 0/4] powercap/dtpm: Add the DTPM framework Hans de Goede
2020-10-12 10:30   ` Daniel Lezcano
2020-10-12 11:46     ` Hans de Goede
2020-10-12 16:02       ` Daniel Lezcano [this message]
2020-10-13 12:47         ` Hans de Goede
2020-10-12 16:37       ` Rafael J. Wysocki
2020-10-13 13:04         ` Hans de Goede
2020-10-14 13:33           ` Rafael J. Wysocki
2020-10-14 14:06             ` Hans de Goede
2020-10-14 15:42               ` Rafael J. Wysocki
2020-10-16 11:10                 ` [RFC] Documentation: Add documentation for new performance_profile sysfs class (Also Re: [PATCH 0/4] powercap/dtpm: Add the DTPM framework) Hans de Goede
2020-10-16 14:26                   ` Elia Devito
     [not found]                     ` <HK2PR0302MB2449214B28438ADC1790D468BD030@HK2PR0302MB2449.apcprd03.prod.outlook.com>
2020-10-16 14:43                       ` Fw: [External] " Mark Pearson
2020-10-16 15:16                         ` Elia Devito
2020-10-16 14:51                   ` Rafael J. Wysocki
2020-10-18  9:41                     ` Hans de Goede
2020-10-18 12:31                       ` Rafael J. Wysocki
2020-10-19 18:43                         ` Hans de Goede
     [not found]                           ` <HK2PR0302MB24494037019FBC7720976735BD1E0@HK2PR0302MB2449.apcprd03.prod.outlook.com>
2020-10-19 18:49                             ` Fw: [External] " Mark Pearson
2020-10-25 10:13                               ` Hans de Goede
2020-10-20 12:34                           ` Rafael J. Wysocki

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=bc1a0134-5242-65d7-a753-fbec0d3bb327@linaro.org \
    --to=daniel.lezcano@linaro.org \
    --cc=hdegoede@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=lukasz.luba@arm.com \
    --cc=rafael@kernel.org \
    --cc=rui.zhang@intel.com \
    --cc=srinivas.pandruvada@linux.intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).